Meu serviço tem um grande número contínuo de eventos do usuário e gostaríamos de fazer coisas como "contar a ocorrência do tipo de evento T desde a data D ".
Estamos tentando tomar duas decisões básicas:
O que armazenar? Armazenando todos os eventos vs. armazenando apenas agregados
- (Estilo do log de eventos) registra todos os eventos e os conta posteriormente, vs.
- (Estilo de série temporal) armazena uma única "contagem de eventos E para a data D " agregada todos os dias
Onde armazenar os dados
- Em um banco de dados relacional (particularmente MySQL)
- Em um banco de dados não relacional (NoSQL)
- Em arquivos de log simples (coletados centralmente na rede via
syslog-ng)
Qual é a prática padrão / onde posso ler mais sobre a comparação dos diferentes tipos de sistemas?
Detalhes adicionais:
- O fluxo total de eventos é grande, potencialmente centenas de milhares de entradas por dia
- Mas nossa necessidade atual é apenas contar certos tipos de eventos dentro dela
- Não precisamos necessariamente de acesso em tempo real aos dados brutos ou resultados de agregação
IMHO, "registre todos os eventos em arquivos, rastreie-os posteriormente para filtrar e agregar o fluxo" é uma maneira UNIX bastante padrão, mas meus compatriotas do Rails-y parecem pensar que nada é real a menos que esteja no MySQL.
architecture
database
metrics
elliot42
fonte
fonte
SELECT...GROUP BY, pode armazenar facilmente os resultados deSELECTs), 2) usando o Graphite para agregação e visualização simples em larga escala, e 3) registrar eventos completos para referência e para assistir detalhes do fluxo de dados em tempo real. Cada um tem sido valioso de maneiras diferentes.Respostas:
Depende sempre, darei meu conselho para oferecer uma nova perspectiva
Se você planeja não perder nenhum detalhe, mesmo que agora não seja relevante, aos meus olhos essa é a melhor abordagem, porque às vezes, conforme os resultados chegam, você encontra outros eventos que para X ou Y não eram relevantes , ou eles não trouxeram nenhuma informação extra, mas, após algumas análises, simplesmente o faz, e você também precisa acompanhar essa, porque, como está gravada, mas não contabilizada, levaria algum tempo para você adicioná-la à imagem .
Se você deseja implementá-lo e usá-lo amanhã, ele pode funcionar, mas se você tiver um novo requisito ou encontrar uma correlação com outro evento que você omitiu por algum motivo, será necessário adicionar esse novo evento e aguardar um pouco. muito tempo para ter bons níveis de agregação
A primeira opção pode ser pesada para um banco de dados se você gravar todos os eventos, então, receio que o MySQL possa ficar muito pequeno e, se você quiser usar soluções RDBMS, poderá pensar em algo maior, como o PostgreSQL ou proprietário como Oracle ou DB2. .
Mas para a agregação seria uma boa opção, dependendo da carga gerada, você pode agregar no código e inserir essas agregações no banco de dados.
Se você optar por esta solução, precisará ver qual abordagem deseja seguir, a boa leitura na wikipedia pode ajudá-lo. Não posso ajudá-lo muito nesse tópico, porque simplesmente não tenho experiência suficiente, principalmente uso rdbms.
Pessoalmente, eu o desencorajaria a optar por essa opção. Se o arquivo crescer muito, seria mais difícil analisar, mas ainda não sei o objetivo principal, é acompanhar o sistema ou simplesmente verificar um log Arquivo ...
Espero que ajude!
fonte
Acho que sua ideia de analisar logs, contar e armazenar resultados em um banco de dados é válida. Não tenho certeza se você gostaria de todos os logs brutos no banco de dados (acho que foi o que você disse que seus compatriotas estão sugerindo). Você já tem os logs nos arquivos, correto? Você pode simplesmente arquivá-las. Suponho que esse bit realmente dependa dos seus casos de uso.
Também concordo com @ Thorbjørn Ravn Andersen sobre como mover sua "resposta de comentário" para a pergunta.
fonte
Depende do uso pretendido. Se você tem um gráfico ou relatório padrão mostrando valores agregados, basta filtrar os eventos à medida que eles chegam e agregá-los no intervalo apropriado. Se você precisar se aprofundar em eventos específicos ou se achar que pode voltar e analisar novamente / categorizar eventos posteriormente, armazene os eventos individuais.
Se você tem tempo e espaço, o que eu normalmente gosto é agregar os dados, mas armazene os detalhes em um arquivo (compactado). Os detalhes não precisam ser facilmente acessíveis, pois quase nunca preciso deles, mas eles estão disponíveis para reprocessamento em massa se os critérios de classificação mudarem.
fonte
Qualquer decisão de arquitetura deve ser orientada pelas necessidades de negócios. No seu caso, você deve ter uma ideia mais clara de quais informações deseja obter do seu sistema de logs e para decidir como armazenar, com que freqüência precisará dessas informações e quanto tempo pode esperar para obter o resultado . É isso que impulsiona o design de coletores de logs, correlacionadores de eventos e aplicativos similares.
Em vez de dar minha opinião, sugiro que você analise alguns aplicativos semelhantes ao que você tenta desenvolver. Alguns deles podem ser muito mais poderosos do que aquilo que você pretende desenvolver, mas não será prejudicial se você observar as políticas de arquitetura e armazenamento seguidas. No lado profissional, você tem aplicativos SIEM, como RSA e Arcsight, e no lado de código aberto, iniciativas como Kiwi ou OSSIM (que também possui uma versão baseada em dispositivo profissional).
Outra coisa a considerar é que, quando você começar a usar os resultados obtidos pela ferramenta, começará a receber muito provavelmente muitas solicitações de sua gerência para obter mais informações e uma mais detalhada. Então ... use-o com cuidado e planeje com a sua visão no horizonte. Isso pode lhe dar mais trabalho, mas definitivamente você pode obter muito suporte e visibilidade (a pressão vem no pacote) ....
fonte