OpenTelemetry helps you collect logs, metrics, traces, and other observability signals from your applications and infrastructure. It’s becoming a de facto standard for observability because it lets you use one consistent way to collect telemetry data, no matter what language, platform, or monitoring solution you’re using.

Sematext now supports OpenTelemetry for Logs and Metrics, enabling you to monitor your own applications, not just the third-party services and the infrastructure they run on.

This means you can now collect, visualize, and alert on application-level metrics such as request rates, latency, and error rates.

Sematext already supports OpenTelemetry Traces, so you can troubleshoot easily by correlating all three signals – logs, metrics, and traces – and correlating across them to pinpoint the root cause.

See our documentation for tracing and our integration for metrics and logs using OpenTelemetry.

What Changed

Before OpenTelemetry Logs & Metrics in Sematext Cloud:

• You could monitor infrastructure and services (Kafka, Nginx, MySQL, JVM, hosts, etc.)
• You could ship application logs
• But you could not:
  • Collect metrics emitted by your own application
  • Chart business or app-level metrics (requests, latency, error rates per service)
  • Alert on application-specific metrics
  • Correlate application metrics ↔ application logs
  • See how your application behaves independently of the infrastructure it runs on

What You Can Do with OpenTelemetry Logs & Metrics

By sending OpenTelemetry data to Sematext Cloud, you can now monitor your own applications as first-class entities, not just their logs or the infrastructure beneath them.

You can:

• Collect and chart application metrics

Track request volume, latency, error rates, and custom metrics emitted by your services independent of the hosts, containers, or platforms they run on.

• Alert on application health and behavior

Set alerts on metrics that actually reflect user experience and service reliability, such as slow endpoints, rising error rates, or degraded throughput.

• Correlate application metrics with application logs

Instantly pivot from a spike or dip in application performance to the exact log events that explain what happened.

• Understand application behavior, not just resource usage

Infrastructure metrics (CPU, memory, JVM, .NET, system metrics) tell you if something is wrong. Application metrics tell you what is wrong and where.

Previously, Sematext Cloud users could ship application logs but had no way to collect or analyze metrics produced by their applications themselves. OpenTelemetry Logs & Metrics changes that, unlocking full application observability in Sematext Cloud.

Correlate OpenTelemetry logs & metrics with events

Given that regressions are introduced when changes and deployments are made, it is very helpful to have deployment and similar events in Sematext. When you do that you will be able to correlate things like errors in logs, or spikes in metrics or duration of traces with operational events such as deployments, restarts, scaling actions, or configuration changes. This makes it easy to see when something broke and why. For example, if latency or error rates increase right after a deployment, you’ll immediately know where to focus your investigation. And if you can include things like commit hashes, PR numbers, etc. in events the investigation will become faster and could even be automated.

Metrics

New Built-in Dashboards

Once OpenTelemetry metrics are shipped to Sematext, you can:

• Use Service Health and Performance reports to monitor request volume, latency, success rates, and error trends across your services.
• Use SDK and runtime-specific reports (Java, .NET, Python) to track application internals such as JVM memory and GC behavior, .NET CPU and garbage collection, Python runtime performance, and process-level resource usage.
• Use Infrastructure and system reports to monitor CPU, memory, disk, network, and thread usage, helping you understand resource consumption and capacity across hosts and services.
• Compare behavior across services using cross-service reports, making it easy to identify slow or underperforming services and spot regressions over time.

New Pre-configured Alert Rules

To help you get started faster, the OpenTelemetry Monitoring App in Sematext comes with default alert rules:

• HTTP Server Error Rate Anomaly Alert – Detects abnormal spikes in 4xx and 5xx responses, indicating application errors or service degradation.
• HTTP Server and Client Latency Anomaly Alerts – Triggered when request processing time or outbound call latency increases unexpectedly, helping you catch performance regressions early.
• High CPU Usage Alert – Alerts when process CPU utilization remains high over a sustained period, signaling resource saturation.
• Database Connection Pool Saturation Alert – Fires when pending database connection requests exceed safe thresholds, indicating pool exhaustion or slow queries.
• Database Connection Timeout Alert – Alerts when database connection timeouts occur repeatedly, often an early sign of database or connectivity issues.
• JVM Memory Pressure Alert – Triggered when JVM memory utilization exceeds safe limits, helping prevent out-of-memory errors.
• Long Garbage Collection Pause Alert – Alerts when JVM GC pauses become excessively long, which can cause request latency spikes and service instability.

Logs

New Built-in Dashboards

Once logs are shipped to Sematext, you can:

• Use the Overview Report to see log volume, severity levels, service activity, and timelines.
• Use the Explore Report to dig into raw logs, filter, save views for common queries for easy access later, and create alerts.
• Correlate logs with events such as deployments, restarts, config changes, or scaling actions, so you can quickly connect changes with system behavior.

New Pre-configured Alert Rules

To help you get started faster, the OpenTelemetry Logs App in Sematext comes with default alert rules:

• Anomaly Alerts – Detect abnormal spikes in error or warning logs.
• Service Heartbeat Alert – Triggered when a service stops sending logs, which may mean it crashed, was stopped, or lost connectivity.
• Infrastructure Resource Exhaustion Alert – Alerts when logs contain signs of critical resource exhaustion (e.g., memory, disk, or connection pool limits). This lets you react quickly before failures cascade.
• Authentication Attack Detection Alert – Flags repeated failed login attempts, which could indicate brute force or credential stuffing attacks.
• Database Connectivity Issues – Alerts when your app logs show database connection problems or query failures. This helps catch DB issues before they impact more of your system.

What’s Next: Tracing

This release focuses on logs and metrics, but tracing support is coming soon.

• With logs, you can monitor detailed events and errors.
• With metrics, you’ll be able to track performance and resource usage over time.
• With traces, you’ll be able to follow requests across services and see where slowdowns or failures happen.

Once all three are supported in Sematext Cloud, you’ll be able to view and correlate them side by side. For example, you’ll be able to:

• See a spike in latency (metrics),
• Trace the slow request path (tracing),
• And check related log entries for detailed context (logs).

This gives you the complete picture of what’s happening in your systems, all in one place.

You can start using OpenTelemetry Logs and Monitoring today by creating OpenTelemetry Logs and Monitoring Apps in Sematext Cloud and following the setup instructions in the UI.

For more information, please refer to OpenTelemetry Integration docs.