Na edição #2204 , um dos desenvolvedores do Prometheus diz:
...em princípio você deveria estar favorecendo
ignoring
aon
produção de regras compartilháveis genéricas...
Estou confuso como o uso de ignoring
levaria a regras mais genéricas. Por exemplo, considere uma situação em que temos uma métrica de "informações" para um dispositivo e várias estatísticas, como esta:
device_info{id="1", owner="coyote", project="acme"}
device_rx_bytes{id="1"}
device_tx_bytes{id="1"}
device_rx_errors{id="1"}
device_tx_errors{id="1"}
Se eu quiser obter a taxa de recebimento por projeto, precisaria correlacionar a device_rx_bytes
métrica com a device_info
métrica correspondente. Para mim, isso cheira a uma junção SQL, e eu escreveria:
rate(device_rx_bytes[5m]) * on(id) group_left(project) device_info
Isso parece "genérico" no sentido de que apenas faz suposições sobre o rótulo usado para o agrupamento ( id
) e o rótulo que queremos propagar para nossos resultados ( project
). Se eu entendi o ignoring
operador corretamente, a expressão correspondente seria mais complexa porque eu precisaria listar todos os rótulos do lado direito que não existem no lado esquerdo. Algo como:
rate(device_rx_bytes[5m]) * ignoring(owner, project) group_left(project) device_info
Isso é correto? E se for, por que é ignoring
preferível on
(não apenas na citação acima, mas também em várias documentações e exemplos)?
Eu acho que a palavra-chave nesse comentário é
shareable
, ou em outras palavras , regras reutilizáveis . Isso significa que você (geralmente) preserva mais rótulos ao usarignoring
em comparação comon
e os resultados serão (geralmente) uma regra com mais rótulos originais intactos, para que possam ser reutilizados para mais cenários.Imagine estas séries temporais:
Uma consulta com
ignoring(rev)
deixa de fora todos os outros rótulos no resultado, em comparação com a mesma consulta comon(app)
.Mas o resultado de
on
eignoring
seria idêntico se você os usasse com um conjunto de rótulos mutuamente exclusivos, como o exemplo que você está mencionando.