Sumologic syslog connection from apigee

Hi,

In our org we have asked sumologic team to provide syslog interface to submit log from apigee cloud.

They have give us a token, host and port.

But in apigee message logging i don’t see an option to provide the token and when I test without the token I don’t see the log in sumo logic.

How do i provide token in the message logging policy? Also, how do I know apigee successfully posted the log in sumo logic.

<Syslog><Message> "{organization.name}.{apiproxy.name}.{environment.name}" </Message><Host>syslog.XXX.sumologic.com</Host><Port>XXXX</Port><Protocol>TCP</Protocol></Syslog>

Thanks,

Krish

The token is not part of the standard syslog interface, and so there is no explicit element in the Syslog configuration for including that token .

According to my reading of the sumologic documentation, you need to embed the token into the message itself. For example, supposing you have the token ABCDEFG12345 , then you might use this configuration:

<Syslog>
  <Message>ABCDEFG12345 {organization.name}.{apiproxy.name}.{environment.name}</Message>
  <Host>syslog.XXX.sumologic.com</Host>
  <Port>XXXX</Port>
  <Protocol>TCP</Protocol>
</Syslog>

You could of course, parameterize the token as well. If you populate the token from a KVM or some other AssignVariable policy, and use the variable name “sumologic.token” , then you could use this alternative policy configuration:

<Syslog>
  <Message>{sumologic.token} {organization.name}.{apiproxy.name}.{environment.name}</Message>
  <Host>syslog.XXX.sumologic.com</Host>
  <Port>XXXX</Port>
  <Protocol>TCP</Protocol>
</Syslog>
1 Like

@Dino

After doing this same configuration I am still not seeing the log in sumo logic. Any idea how can i debug or what else i should look for?

@Dino

It is working after adding the below snippet. One question, when i see the log in sumo, it actual log is getting appended with “<14>1 2018-02-27T21:31:05.005+0000 19ea1fc2-e676-418b-b8e1-848da00a2732 Apigee-Edge - - -”. Do you know how can i get rid of this?

<FormatMessage>true</FormatMessage><strong><SSLInfo><Enabled>true</Enabled></SSLInfo><br></strong>

Yes - that information is added by the MessageLogging policy when you include the FormatMessage element. Read more about that here: https://docs.apigee.com/api-services/reference/message-logging-policy

You may try excluding that element or setting it to false, while keeping SSLInfo.

Eg

<FormatMessage>false</FormatMessage>
<SSLInfo>
  <Enabled>true</Enabled>
</SSLInfo> 

@Dino

With

<FormatMessage>false</FormatMessage>

Log content is prepended with “<14>Tue Feb 27 22:05:46 UTC 2018Info:”

Any thoughts?

Did you try removing that FormatMessage element completely?

I don’t know why that stuff is still there.

The documentation states:

  • <14> - A priority score (see the Syslog Protocol) based on the log level and facility level of the message.
  • Date with a UTC offset (UTC = +0000).

I don’t know if it is possible to remove or eliminate that from the message that gets sent to Sumo.

@Dino

I have removed the “FormatMessage” from the proxy. I can still see the extra chars in sumologic.

@Krish

I reviewed my notes on this, and have found a known issue concerning message logging. b/68722102 - MessageLogging FormatMessage False Not Working

Per this known issue, the expectation is that with FormatMessage set to “false”, only the message part of the syslog, and exclude:
the syslog priority score <14>,
extra date timestamp,
syslog token
Currently the way that FormatMessage set to “false” works, only the syslog token is excluded.

We are using sumologic free acccount. How can i test message logging policy. I am able to log error messages from shared flow using the JS approach suggested at https://community.apigee.com/articles/32286/logging-to-sumo-logic-using-javascript-and-http.html. But for asynchronous and postclient flow i need to test with free account especially success responses. Is it possible. thanks

Hi

for new questions, ask a new question. Do not post new questions as comments on comments on answers to old questions.

Sure i will.

I can confirm that this bug is still present in Edge Cloud, as of 2018-11-15.