Потеря метрик с одинаковым именем и разными тегами с помощью агента Otel-java, сплава и мимира ⇐ JAVA

[Anonymous]

Я использую Java-агент OpenTelemetry для считывания и передачи показателей микрометра из моего Java-приложения в Alloy, а затем из Alloy в Mimir, который затем считывается в графане.
micrometer -> агент opentel -> сплав -> mimir -> grafana
У меня есть три показателя:

Код: Выделить всё

// Registered in service A
this.incomingCounter = Counter.builder("direct_auth_requests_total")
.tag("outcome", "incoming")
.register(meterRegistry);

// Regitered in service B
this.completedCounter = Counter.builder("direct_auth_requests_total").tag("outcome", "completed").register(meterRegistry);
this.failedCounter = Counter.builder("direct_auth_requests_total").tag("outcome", "failed").register(meterRegistry);

Они всегда увеличиваются в других входящих -> завершенных или неудачных

MeterRegistry вводится через Spring.
Я знаю, что они увеличиваются правильно, и могу видеть их независимо, используя конечную точку Prometheus, предоставляемую Spring-boot.
Однако в Grafana я получу только первую метрику, result=incoming. Остальные кажутся заблудиться. У меня есть другие счетчики, которые следуют той же схеме: одно имя имеет несколько тегов, и у них возникает та же проблема. Только первый из них регистрируется в графане.
Вот соответствующие части конфигурации сплава:

Код: Выделить всё

// OTLP Receiver
otelcol.receiver.otlp "collector" {
grpc {
endpoint = "0.0.0.0:4317"
}
http {
endpoint = "0.0.0.0:4318"
}

output {
metrics = [otelcol.processor.attributes.add_attributes.input]
}
}

// Attributes Processor to add system_name and server_name labels
otelcol.processor.attributes "add_attributes" {
action {
key    = "region"
value  = "{{ system_region }}"
action = "insert"
}
action {
key    = "system"
value  = "{{ system_name }}"
action = "insert"
}
action {
key    = "host"
value  = "{{ inventory_hostname }}"
action = "insert"
}

output {
metrics = [otelcol.processor.transform.sanitize_resource_attrs.input]
}
}

// Delete oversized resource attributes from METRICS before sending to Mimir
// These attributes get added to target_info and exceed Mimir's 2048 byte limit
otelcol.processor.transform "sanitize_resource_attrs" {
error_mode = "propagate"

metric_statements {
context = "resource"
statements = [
// Delete attributes that can exceed 2048 bytes
"delete_key(resource.attributes, \"process.command_args\")",
"delete_key(resource.attributes, \"process.command_line\")",
"delete_key(resource.attributes, \"process.executable.path\")",
]
}

output {
metrics = [otelcol.processor.batch.mimir.input]
}
}

// Basic Auth credentials for Tempo, Mimir, and Loki
otelcol.auth.basic "creds" {
username = "{{ username }}"
password = "{{ password }}"
}

// Mimir Exporter
otelcol.exporter.otlphttp "mimir" {
client {
endpoint = "{{ mimir_endpoint }}/otel"
headers = {
"X-Scope-OrgID" = "{{ org_id }}",
}
auth     = otelcol.auth.basic.creds.handler
}
}

otelcol.processor.batch "mimir" {
output {
metrics = [otelcol.exporter.otlphttp.mimir.input]
}
}

Мы используем конечную точку mimir/otel. Конечная точка Прометея вызвала множество других проблем. Журналы сплавов пусты, и я вижу, что на графике сплавов метрики, похоже, проходят (что имеет смысл, поскольку очевидно, что первый счетчик проходит)

Подробнее здесь: https://stackoverflow.com/questions/799 ... agent-allo