Skip to content

Tag: API

Log Insight: Ingestion API versus Syslog Protocol Part 2/2

In my last post, I talked about the differences between how events are displayed over the syslog protocol, which has a strict format structure, and the ingestion API, which sends events as-is. In this post, I would like to talk about the differences between using the syslog protocol versus the ingestion API when it comes to the Log Insight agent and the Log Insight forwarder.
not_equal_to_u2260_icon_256x256

Log Insight: Ingestion API versus Syslog Protocol Part 1/2

As you know, Log Insight introduced an ingestion API with the 2.0 release. This ingestion API can be used by anyone, but is leveraged by default by the Log Insight agent available for Windows as of 2.0 and Linux as of 2.5. The ingestion API is powerful because it provides functionality beyond what the syslog RFC defines, but it is important to note that events received over each protocol may look different. Read on to learn more.
not_equal_to_u2260_icon_256x256

12 Reasons Why You Should Use The Log Insight Agent

When the Log Insight Windows agent was released in version 2.0, the decision to use the agent was easy because Windows does not natively support syslog. Given the release of the Log Insight Linux agent, I have been asked a few times why the agent should be used over already available syslog agents like Rsyslog and Syslog-NG for sending events to a remote destination like Log Insight. I would like to cover 12 reasons in this post.
li-agent

Log Insight: Using the Ingestion API

As I am sure you know, Log Insight 2.0 features an ingestion API, which makes it possible to ingest information without use of the syslog protocol. The API uses a JSON string to send events to Log Insight and also supports the ability to pass fields during ingestion time. An example of a JSON message would be:

Depending on your operating system, you have a variety tools to send API events like the above. For example:

Depending on the method you choose and the format in which you pass the information you will get one of the following return codes:

  • 200 OK
  • 400 Bad Request
  • 500 Internal Server Error
  • 503 Service Unavailable

Unless you receive 200 OK something is wrong that needs to be corrected. If you get 503 Service Unavailable then the issue is either server-side or network related. The 400 and 500 error codes point to a client-side error. The question becomes, how do you fix client-side errors?
api