OTLP over gRPC and HTTP
Connect compatible OpenTelemetry producers and Collectors through the supported OTLP/gRPC or OTLP/HTTP profile. Evaluate protected transport, scoped authentication and the endpoint appropriate to your deployment.
Open telemetry. Governed ingestion.
Connect application signals to infrastructure reality.
Bring OpenTelemetry metrics, structured logs and bounded sampled span evidence into AmrudAi’s operational context. Connect each signal to the right entity and service, then investigate it alongside the network and infrastructure that service depends on.
The application experience
Logs & operational events
See the complete workspace. Enlarge any image to inspect its panels, navigation and evidence at actual size.
Logs, Syslog & Operational Events — illustrative product view with sample data. Illustrative product view · Sample data
Search normalized events while preserving raw messages, provenance and service context. Temporal Topology & Service Dependencies — illustrative product view with sample data. Illustrative product view · Sample data
Replay relationships at the time of an incident without overwriting them with current state. The capability in detail
OpenTelemetry & OTLP capabilities
Authenticated source authority
Bind incoming telemetry to the authorized source, site and customer on the server. A caller-supplied attribute does not grant access to another customer’s data.
Resource and instrumentation context
Preserve Resource and Instrumentation Scope metadata, plus supplied schema and semantic-convention provenance. Keep the meaning and origin of a signal alongside its value.
Metrics with correct semantics
Respect supported units, monotonic counters, aggregation temporality and histogram semantics. Validate the actual instruments emitted by your telemetry pipeline rather than treating all numbers alike.
Structured logs and trace references
Retain timestamps, severity, bounded message bodies and permitted attributes, including trace_id and span_id when present. Follow log evidence into related sampled spans, service dependencies and infrastructure observations.
Service and entity mapping
Associate accepted service and workload observations with the canonical resource model. Connect cloud, Kubernetes and infrastructure evidence while keeping platform authorization independent of external identifiers.
Visible pipeline outcomes
Account for accepted, rejected and dropped records. Expose source health, freshness, queue pressure and schema problems so a broken telemetry path is not mistaken for a service outage.
Governed volume and data boundaries
Apply payload, attribute, rate and cardinality bounds alongside configured minimization and redaction. Validate representative load and permitted data before enabling the production ingestion profile.
From information to action
A connected operational workflow.
- 01
Connect the producer
Select the supported Collector or SDK export profile and protected endpoint.
- 02
Validate the contract
Confirm authentication, resource mapping, instrument semantics and permitted attributes.
- 03
Follow the service context
Correlate accepted signals with the associated cloud, host, network and Kubernetes resources.
- 04
Inspect pipeline health
Review freshness and accepted/rejected accounting alongside the monitored service.
Metrics, logs and sampled span evidence
Fit the way your team operates.
Receive OpenTelemetry metrics and structured logs over OTLP, preserve correlation context and use bounded sampled spans with trace-derived dependency summaries for operational investigation.
- Connect compatible OTLP/gRPC or OTLP/HTTP exporters using scoped authentication, supported metric types and explicit resource attributes.
- Control span sampling, retention, cardinality and resource budgets while retaining the source and quality of dependency evidence.
- Separate collector backlog, rejected data and source freshness from service health. Missing sampled spans do not prove that a request or dependency did not exist.
Connect the workflow
What does OpenTelemetry collection include?
What is the difference between OpenTelemetry and OTLP?
OpenTelemetry is a common approach to collecting and describing telemetry; OTLP transports it. AmrudAi receives metrics, structured logs and bounded sampled span evidence, then relates those signals to operational entities and service dependencies.
Does this replace my distributed tracing or APM platform?
AmrudAi connects metrics, logs, trace context and bounded sampled span evidence with infrastructure and network investigations. Teams can retain a specialist APM platform for developer workflows such as complete application tracing, profiling or user-session analysis.
Can I keep my existing OpenTelemetry Collector?
Yes. Configure a compatible Collector export path to AmrudAi’s OTLP endpoint with the required transport, authentication, resource attributes and instrument types. Set sampling and throughput budgets appropriate to your collection profile.
How are excessive labels and event rates handled?
The ingress design includes rate, payload, attribute and cardinality bounds with explicit acceptance and rejection evidence. Agree limits using representative traffic, since one universal limit would be misleading.
See the workflow in your environment.
Explore the technology, service dependencies and operating requirements that matter to your team.