API monitoring¶

Complementing traces¶

Tracing is a very powerful technique to understand how a distributed system works but it is not without its challenges. The initial setup, specially in medium to large complex systems, can be time-consuming and if not done properly you may end up with visibility gaps. The initial cost setup may slow down its adoption across the whole organization.

Additionally, traces are excellent for understanding the flow of requests through your system. They typically focus on the interaction between different components or services within an application identifying latency issues and the source of a failed request but they might not provide insight into the internal workings of those components.

While traces are request-oriented, Neblic provides information about all the data that went trough a particular point of your application. This can help you identify problems and behaviurs that traces typically overlook and that are usually the reflection of internal problems in the logic of your application.

How can Neblic help?¶

Microservices communications¶

In a microservice architecture, an application is divided into smaller, independent services that each perform a specific function. This structure allows for more flexibility, scalability, and provides clear boundaries between components. However, the need for these microservices to communicate with one another introduces complexity. The communication is typically facilitated through Remote Procedure Calls (RPCs) or REST APIs.

With Neblic you can get visibility into these interactions between microservices by intercepting their requests and responses. Typical problems that you can diagnose:

• Schema violations: Get a schema inferred from the payload of requests and responses which will allow you to see their fields and types. For example, you can detect if an id or timestamp that was supposed to be a string is sent as an integer or if a field that was supposed to be deprecated is still being used.
• Incorrect API usages: Keep track of how each microservice API is being called. Identify if requests have nulls, empty or unexpected values by monitoring statistics per field.
• Find the root cause of bugs: If an invalid payload or response is detected in the system you can navigate upstream through all the services involved in a particular problem to exactly see which one is the source of the error.

Monitor third-party APIs¶

Nowadays, most applications use third-party APIs that are not under your control. Monitoring them can provide many insights and help you get better visibility into their behavior, for example:

• Breaking changes: There are applications that heavily rely on third-party APIs that may not be as stable or consistent as desired. By monitoring the request and response payloads of these APIs, you can identify if a bug in your application results from a breaking change in the API.
• Documentation: You can also monitor third-party APIs to track changes even if they are not breaking your application. Maybe there is new information or new fields that you find useful for your application.
• Usage: Another interesting use case is to monitor third-party APIs to understand how your application is using them. For example, you can get more granularity into how your application is using an endpoint to better understand its costs.

Keep an eye on user facing APIs¶

If your application exposes an API that is directly consumed by your clients, you can use Neblic to get observability over the data served to them.

Usually, once the response payload has been generated by an application it is simply returned to the user and is not monitored in any way. Using Neblic to monitor the structure, and more importantly, the actual data returned to your users, you can detect when something is wrong without needing them to notify you.