Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Importante
Esta página inclui instruções para gerir componentes do Azure IoT Operations usando manifestos de implementação do Kubernetes, que estão em pré-visualização. Esse recurso é fornecido com várias limitações e não deve ser usado para cargas de trabalho de produção.
Consulte os Termos de Utilização Complementares das Visualizações Prévias do Microsoft Azure para obter os termos legais que se aplicam às funcionalidades do Azure que estão em beta, em pré-visualização ou que ainda não foram lançadas para disponibilidade geral.
Os endpoints de fluxo de dados do OpenTelemetry são utilizados para enviar métricas e logs aos coletores OpenTelemetry, que podem então encaminhar os dados para plataformas de observabilidade, como dashboards Grafana e Azure Monitor. Pode configurar definições de ponto de extremidade, autenticação, segurança da camada de transporte (TLS) e opções de lote.
Pré-requisitos
- Uma instância do Azure IoT Operations
- Um coletor OpenTelemetry implantado e acessível a partir do cluster de Operações IoT do Azure
Visão geral do endpoint OpenTelemetry
Os endpoints OpenTelemetry facilitam a exportação de dados de telemetria dos fluxos de dados do Azure IoT Operations para coletores OpenTelemetry usando o Protocolo OpenTelemetry (OTLP). Isso permite que você integre a telemetria do dispositivo e do sistema à sua infraestrutura de observabilidade existente.
Cenários comuns
- Diagnóstico do dispositivo: exporte temperatura, pressão e outras leituras do sensor como métricas para monitorar a integridade do dispositivo
- Monitoramento de fábrica: envie telemetria da linha de produção para painéis Grafana para visibilidade operacional
- Observabilidade do sistema: Encaminhe logs e métricas de aplicativos para o Azure Monitor para monitoramento centralizado
- Métricas personalizadas: adicione atributos contextuais, como ID de fábrica ou localização, às métricas para melhor filtragem e análise
Requisitos relativos ao formato dos dados
Os pontos de extremidade OpenTelemetry exigem que os dados estejam em conformidade com um esquema JSON específico com uma matriz metrics, uma matriz logs ou ambas. As mensagens que não estão em conformidade com esse esquema são descartadas e reconhecidas para evitar a perda de mensagens.
A carga útil JSON deve usar esta estrutura de nível superior:
{
"metrics": [ /* array of metric objects */ ],
"logs": [ /* array of log objects */ ]
}
Pelo menos um dos metrics ou logs deve estar presente.
Todas as mensagens recebidas são validadas em relação ao esquema necessário. As mensagens que falham na validação são descartadas, reconhecidas de volta ao broker e registradas para solução de problemas. Falhas comuns de validação incluem campos obrigatórios ausentes, tipos de dados inválidos, tipos de métricas ou níveis de log sem suporte e carimbos de data/hora malformados. Se as mensagens MQTT incluírem carimbos de data/hora de expiração, as mensagens expiradas serão filtradas antes do processamento.
Formato das métricas
Cada objeto métrico na metrics matriz deve conter os seguintes campos:
Campos obrigatórios:
-
name(string): O nome da métrica -
type(string): O tipo de métrica (consulte tipos de métricas suportados) -
value(número): O valor numérico da métrica
Campos opcionais:
-
description(string): Descrição legível por humanos da métrica -
timestamp(número): Timestamp da Unix epoch em nanossegundos quando a métrica foi registada -
attributes(array): pares chave-valor para rotulagem e filtragem de métricas
{
"metrics": [
{
"name": "temperature",
"description": "The temperature reading from sensor",
"type": "f64_gauge",
"value": 72.5,
"timestamp": 1754851200000000000,
"attributes": [
{
"key": "factoryId",
"value": "factory1"
},
{
"key": "location",
"value": "warehouse"
}
]
}
]
}
Cada atributo na attributes matriz deve ter:
-
key(string): O nome do atributo -
value(string): O valor do atributo (deve ser uma string)
Formato de registos
Cada objeto de log na logs matriz deve conter os seguintes campos:
Campos obrigatórios:
-
value(string): Registrar o conteúdo da mensagem -
level(string): Nível de log (consulte os níveis de log suportados)
Campos opcionais:
-
timestamp(número): Carimbo temporal da época Unix, expresso em nanossegundos, quando o registo foi criado -
attributes(array): pares chave-valor para o contexto de log e filtragem
{
"logs": [
{
"value": "Device temperature sensor initialized",
"level": "info",
"timestamp": 1754851200000000000,
"attributes": [
{
"key": "deviceId",
"value": "sensor001"
},
{
"key": "component",
"value": "temperature-sensor"
}
]
}
]
}
Cada atributo na attributes matriz deve ter:
-
key(string): O nome do atributo -
value(string): O valor do atributo (deve ser uma string)
Tipos de métricas suportados
Os seguintes tipos de métricas OpenTelemetry são suportados:
- Contadores:
u64_counter,f64_counter- Valores monotonicamente crescentes - Contadores ascendentes/descendentes:
i64_up_down_counter,f64_up_down_counter- Valores que podem aumentar ou diminuir - Medidores:
u64_gauge,i64_gauge,f64_gauge- Valores momentâneos - Histogramas:
f64_histogram,u64_histogram- Distribuição dos valores
Níveis de log suportados
Os seguintes níveis de log são suportados:
tracedebuginfowarnerrorfatal
Criar ponto de extremidade OpenTelemetry
Você pode criar um ponto de extremidade de fluxo de dados OpenTelemetry usando a experiência de operações, Bicep ou Kubernetes.
Para criar um dataflow OpenTelemetry na experiência de operações, vá para os endpoints do Dataflow.
Na página de terminais do fluxo de dados, identifique Open Telemetry e selecione + Nova.
No painel Criar novo ponto de extremidade de fluxo de dados: abrir Telemetria , selecione a guia Configuração básica e forneça as seguintes informações:
- Nome: Um nome exclusivo para o endpoint.
-
Host: O endpoint do OpenTelemetry Collector no formato
<host>:<port>, por exemplo,otel-collector.monitoring.svc.cluster.local:4317. -
Método de autenticação: escolha um dos seguintes métodos de autenticação:
- Token de conta de serviço do Kubernetes: usa tokens de conta de serviço do Kubernetes para autenticar com o coletor OpenTelemetry. Forneça o valor de audiência para sua configuração de coletor OpenTelemetria. Consulte Token de conta de serviço (SAT) para obter mais detalhes.
- Anónimo: Use quando o coletor OpenTelemetry não exigir autenticação.
- Certificado X509: usa certificados de cliente para autenticação TLS mútua. Forneça o nome de um segredo do Kubernetes que contém o certificado do cliente. Consulte o certificado X.509 para obter mais detalhes.
Selecione a guia Configuração avançada e forneça as seguintes informações:
- Latência de lote (em segundos): Tempo máximo de espera antes de enviar um lote. O padrão é 5 segundos.
- Contagem de mensagens: número máximo de mensagens em um lote. O padrão é 100000 mensagens.
-
Modo TLS: escolha um dos seguintes modos TLS:
- Habilitado: habilita o TLS para comunicação segura com o coletor OpenTelemetria. Forneça o nome de um Kubernetes ConfigMap contendo seu certificado de CA confiável.
- Desativado: desativa o TLS.
- Nome do mapa de configuração do certificado CA confiável: o nome de um ConfigMap do Kubernetes que contém o seu certificado CA confiável.
Selecione Aplicar para criar o ponto de extremidade OpenTelemetry.
Opções de configuração
Esta secção descreve as opções de configuração para os endpoints do fluxo de dados OpenTelemetry.
Host
A host propriedade especifica a URL do ponto de extremidade do coletor OpenTelemetria. Inclua o protocolo (http:// ou https://) e o número da porta.
Examples:
https://otel-collector.monitoring.svc.cluster.local:4317http://localhost:4317https://otel-collector:4317
Authentication
Os endpoints OpenTelemetry suportam vários métodos de autenticação para garantir uma ligação segura aos coletores.
Token de Conta de Serviço (SAT)
A autenticação de token de conta de serviço (SAT) utiliza tokens de conta de serviço do Kubernetes para autenticar com o coletor do OpenTelemetry.
Substitua <OTEL_AUDIENCE> pelo valor de audiência para sua configuração do coletor OpenTelemetria. Esse valor deve corresponder ao público esperado no coletor.
No painel Criar novo ponto de extremidade de fluxo de dados: Open Telemetria, na guia Configuração básica, selecione Token de conta de serviço do Kubernetes como método de autenticação.
Forneça o valor de audiência de serviço para sua configuração do coletor OpenTelemetria.
Importante
Você só pode escolher o método de autenticação quando criar um novo endpoint de fluxo de dados OpenTelemetry. Não é possível alterar o método de autenticação após a criação do ponto de extremidade do fluxo de dados do OpenTelemetry. Se desejar alterar o método de autenticação de um fluxo de dados existente, exclua o fluxo de dados original e crie um novo com o novo método de autenticação.
certificado X.509
A autenticação de certificado X.509 usa certificados de cliente para autenticação TLS mútua.
No painel Criar novo ponto de extremidade de fluxo de dados: abrir Telemetria , na guia Configuração básica , selecione Certificado X509 como o método de autenticação.
Forneça as seguintes informações do Azure Key Vault:
- Nome secreto sincronizado: o nome de um segredo do Kubernetes que contém o certificado do cliente.
- Certificado de cliente X509: O certificado do cliente.
- Chave de cliente X509: A chave privada para o certificado do cliente.
- Certificados intermediários X509: Os certificados intermediários para a cadeia de certificados do cliente.
Antes de usar a autenticação de certificado X.509, crie um segredo do Kubernetes com seu certificado de cliente:
kubectl create secret tls <X509_SECRET_NAME> \
--cert=client.crt \
--key=client.key \
-n azure-iot-operations
Autenticação anónima
A autenticação anônima é usada quando o coletor OpenTelemetry não requer autenticação.
No painel Criar novo ponto de extremidade de dados: Open Telemetry, na guia Configuração Básico, selecione Anónimo como o método de autenticação. Não são necessárias configurações adicionais.
Configuração do TLS
Configure as configurações de Transport Layer Security (TLS) para comunicação segura com o coletor OpenTelemetry .
TLS habilitado com CA confiável
- No painel Criar novo ponto de extremidade de fluxo de dados: abrir Telemetria , na guia Configuração avançada , selecione Habilitado como o modo TLS.
- Em Nome do mapa de configuração do certificado de CA confiável, forneça o nome de um ConfigMap do Kubernetes que contém o seu certificado de CA confiável.
TLS desativado
No painel Criar novo ponto de extremidade de fluxo de dados: abrir Telemetria , na guia Configuração avançada , selecione Desabilitado como o modo TLS.
Batching
Configure as configurações de processamento em lote para otimizar o desempenho agrupando várias mensagens antes de enviar para o coletor.
No painel Criar Novo Ponto de Extremidade para Fluxo de Dados: Open Telemetry, na guia Configuração Avançada, forneça as seguintes configurações de lote:
- Latência de lote (em segundos): Tempo máximo de espera antes de enviar um lote. O padrão é 5 segundos.
- Contagem de mensagens: número máximo de mensagens em um lote. O padrão é 100000 mensagens.
Tratamento de erros e solução de problemas
Validação de mensagens
Os pontos de extremidade OpenTelemetry validam as mensagens de entrada em relação ao esquema necessário. Mensagens inválidas são descartadas e reconhecidas para evitar a perda de mensagens no pipeline de fluxo de dados.
Erros comuns de validação:
- Faltam campos obrigatórios (
name,type,valuepara métricas;value,levelpara logs) - Tipos de métricas ou níveis de log inválidos
- Valores não numéricos em campos métricos
value - Valores de timestamp malformados
Garantias de entrega
O endpoint OpenTelemetry fornece garantias de entrega para o próprio coletor, mas não para serviços anteriores aos quais o coletor pode encaminhar dados. Quando os dados chegam ao coletor, as Operações IoT do Azure não têm visibilidade sobre se chegam ao destino final.