{"id":25841268,"url":"https://github.com/michaeldouglaspix/watchdog-api","last_synced_at":"2026-04-13T13:03:30.568Z","repository":{"id":279905159,"uuid":"918445136","full_name":"MichaelDouglasPIX/watchdog-api","owner":"MichaelDouglasPIX","description":"A personal project designed to practice the concepts of observability and monitoring using Prometheus,  Grafana. and Loki.","archived":false,"fork":false,"pushed_at":"2025-02-28T05:05:08.000Z","size":12603,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-02-28T12:39:55.744Z","etag":null,"topics":["alertmanager","docker","grafana","jaeger","nginx","node-exporter","nodejs","prometheus","typescript"],"latest_commit_sha":null,"homepage":"","language":"TypeScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/MichaelDouglasPIX.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2025-01-18T00:31:36.000Z","updated_at":"2025-02-28T05:05:11.000Z","dependencies_parsed_at":"2025-02-28T12:52:01.688Z","dependency_job_id":null,"html_url":"https://github.com/MichaelDouglasPIX/watchdog-api","commit_stats":null,"previous_names":["michaeldouglaspix/watchdog-api"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/MichaelDouglasPIX%2Fwatchdog-api","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/MichaelDouglasPIX%2Fwatchdog-api/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/MichaelDouglasPIX%2Fwatchdog-api/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/MichaelDouglasPIX%2Fwatchdog-api/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/MichaelDouglasPIX","download_url":"https://codeload.github.com/MichaelDouglasPIX/watchdog-api/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":241319561,"owners_count":19943554,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["alertmanager","docker","grafana","jaeger","nginx","node-exporter","nodejs","prometheus","typescript"],"created_at":"2025-03-01T05:22:56.032Z","updated_at":"2026-04-13T13:03:30.521Z","avatar_url":"https://github.com/MichaelDouglasPIX.png","language":"TypeScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"\u003ch1 align=\"center\"\u003e🔎 Watchdog API \u003c/h1\u003e\n\n\u003cp align=\"center\"\u003e\n  WatchdogAPI é um projeto pessoal criado para praticar e compartilhar conceitos de observabilidade e monitoramento em Node.js. Esta API simples gera logs, métricas e traces, permitindo uma visão completa do seu funcionamento em tempo real. \n\u003c/p\u003e\n\n\u003cp align=\"center\"\u003e\n  \u003cimg src=\"images/Project-Infrastructure.PNG\" width=\"700\"/\u003e\n\u003c/p\u003e\n\n## 📚 Conceitos Abordados\n\nAntes de seguirmos para os componentes do monitoramento, é importante entender o que é SRE.\n\n### SRE (Site Reliability Engineering)\n\nSRE é um framework que busca garantir que sistemas, sites e softwares sejam **confiáveis** e **altamente disponíveis**. Para alcançar esses objetivos, ele adota **práticas**, **princípios** e **ferramentas** que ajudam a manter a estabilidade dos serviços.\n\nAlguns princípios essenciais do SRE que orientam a construção de um monitoramento eficaz incluem:\n\n- **SLO (Service Level Objective - Objetivo de Nível de Serviço):** Define a meta de disponibilidade da aplicação. Por exemplo, um SLO de 99% significa que a aplicação deve estar disponível 99% do tempo.\n- **Error Budget (Orçamento de Erros):** Determina quanto tempo de indisponibilidade é aceitável. Se o SLO for 99%, o error budget será 1%, indicando que a aplicação pode ficar fora do ar por até 1% do tempo.\n- **SLI (Service Level Indicator - Indicador de Nível de Serviço):** Conjunto de métricas que permitem avaliar se o SLO está sendo cumprido. Exemplos incluem taxa de erros, latência e número de requisições bem-sucedidas, que ajudam a mensurar a disponibilidade da aplicação.\n\nEsses princípios já são suficientes para avançarmos neste projeto. Caso queira se aprofundar mais em SRE, recomendo a leitura do [workbook](https://sre.google/workbook/how-sre-relates/) da Google e do documento sobre [SLOs](https://sre.google/workbook/slo-document/) da Google.\n\n### Observabilidade\n\nAplicações modernas são compostas por diversos componentes, APIs, microserviços e sistemas distribuídos, o que pode dificultar a análise quando ocorre algum problema. A observabilidade busca fornecer dados e informações que permitam entender o estado e o comportamento da aplicação, bem como todos os componentes que fazem parte da infraestrutura do serviço.\n\nCom isso, é possível identificar gargalos de desempenho, explorar o uso de hardware e diagnosticar erros desconhecidos.\n\nA observabilidade é composta por três pilares principais:\n\n- **Logs:** Registros de eventos, erros e operações do sistema. É importante estruturá-los e padronizá-los para garantir informações essenciais e facilitar a análise da jornada de execução das aplicações.\n- **Métricas:** Dados numéricos coletados dentro de uma série temporal, permitindo acompanhar o comportamento da aplicação em períodos definidos. Exemplos comuns incluem métricas de CPU, latência, número de requisições e erros.\n- **Traces:** Rastreamento de transações end-to-end dentro da aplicação, permitindo identificar gargalos de desempenho e dependências entre serviços.\n\nEste projeto implementa os três pilares da observabilidade para garantir uma análise detalhada do sistema.\n\n### Monitoramento\n\nApós tornar a aplicação observável, é possível implementar o monitoramento contínuo para acompanhar a saúde do sistema. Isso inclui a análise de **SLIs** e regras de negócio por meio de dashboards, além da configuração de alertas para notificar as pessoas responsáveis quando ocorrerem problemas, como:\n\n- Serviços fora do ar\n- Estouro de memória\n- Queda no volume de dados em períodos de pico de acesso\n\nO monitoramento tem os seguintes objetivos principais:\n\n- **Reagir a problemas** conhecidos por meio de alertas\n- **Permitir o acompanhamento de dados** através de gráficos e dashboards\n- **Reduzir o tempo de detecção de problemas**, medir impacto e otimizar a análise da causa raiz\n\nAgora que entendemos o que é **observabilidade** e **monitoramento**, podemos explorar as ferramentas utilizadas neste projeto.\n\n## ⚙️ Ferramentas\n\n\u003ch3\u003e\u003cimg align=\"center\" width=\"50\" src=\"https://skillicons.dev/icons?i=prometheus\" style=\"padding-right: 10px;\"\u003e Prometheus\u003c/h3\u003e\n\nO Prometheus é uma ferramenta de **monitoramento** e **observabilidade** usada para coletar e armazenar séries temporais identificadas como métricas, organizadas em pares chave-valor. Essas séries temporais podem ser armazenadas localmente no banco de dados embutido do Prometheus ou em um armazenamento remoto.\n\nEle suporta diversos exporters para coletar métricas. Neste projeto, o Prometheus coleta e armazena métricas do **node-exporter** e da aplicação **WatchdogAPI**.\n\nA partir dessas séries temporais armazenadas, é possível:\n\n- Analisar e filtrar métricas utilizando consultas avançadas\n- Gerar alertas para problemas através da integração com o Alertmanager\n- Visualizar os dados em tempo real integrando com o Grafana\n\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"./images/gifs/prometheus-interface.gif\" alt=\"Prometheus interface\" width=\"500\" style= \"padding-top: 10px;\"/\u003e\n\u003c/p\u003e\n\nPara mais informações, acesse a página do [**Prometheus**](https://prometheus.io/docs/introduction/overview/).\n\n\u0026nbsp;\u0026nbsp;\u0026nbsp;\n\n\u003ch3\u003e\u003cimg align=\"center\" width=\"50\" src=\"./images/logos/node-exporter-logo.png\" style=\"padding-right: 10px;\"\u003e Node Exporter\u003c/h3\u003e\n\nO **Node Exporter** é um exportador de métricas para o **Prometheus**, utilizado para monitorar a infraestrutura de servidores, coletando métricas de desempenho e informações sobre o estado do servidor.\n\nPor padrão, o Node Exporter coleta diversas métricas que são essenciais para o monitoramento da saúde do servidor. Neste projeto, estamos utilizando algumas dessas métricas, como o uso de **memória** e **CPU**.\n\nO **Node Exporter** expõe essas métricas em um endpoint HTTP, que o **Prometheus** consulta periodicamente para armazenar e analisar os dados.\n\nPara mais informações, acesse o repositório oficial do Node Exporter: [Node Exporter no GitHub](https://github.com/prometheus/node_exporter).\n\n\u0026nbsp;\u0026nbsp;\u0026nbsp;\n\n\u003ch3\u003e\u003cimg align=\"center\" width=\"50\" src=\"./images/logos/alert-manager-logo.png\" style=\"padding-right: 10px;\"\u003e Alert Manager\u003c/h3\u003e\n\nO **Alert Manager** é um componente do Prometheus responsável por gerenciar os alertas quando as condições definidas nas métricas do Prometheus são atendidas. Ele recebe os dados e encaminha as notificações para os canais configurados, como Slack, Email, Discord, entre outros.\n\nO Alert Manager permite:\n\n- Agrupar alertas para evitar o envio excessivo de notificações.\n- Silenciar alertas, o que é útil quando o sistema está em manutenção ou quando a equipe já está trabalhando na resolução de um erro.\n- Enviar alertas para diferentes canais, com a possibilidade de configurar canais específicos de acordo com o nível de severidade.\n- Por ser um componente do Prometheus, permite centralizar as configurações de alerta de diferentes exporters.\n\nNeste projeto, estaremos notificando por **email** dois alertas:\n\n- **SLO Break**: Alerta quando 90% das requisições forem maiores que 500ms nos últimos 1 minuto.\n- **ERROR 500**: Alerta quando o volume de erros 500 for maior que 20% no total de requisições nos últimos 5 minutos.\n\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"./images/gifs/alert-manager-interface.gif\" alt=\"Prometheus interface\" width=\"500\" style= \"padding-top: 10px;\"/\u003e\n\u003c/p\u003e\n\nPara mais informações, acesse a página do Prometheus sobre o [**Alert Manager**](https://prometheus.io/docs/alerting/latest/overview/).\n\n\u0026nbsp;\u0026nbsp;\u0026nbsp;\n\n\u003ch3\u003e\u003cimg align=\"center\" width=\"50\" src=\"./images/logos/loki-logo.png\" style=\"padding-right: 10px;\"\u003e Loki\u003c/h3\u003e\n\nO Loki é uma ferramenta de log aggregation responsável por coletar, armazenar e permitir a consulta de logs. Ele centraliza os registros de diferentes sistemas e aplicações em um único componente, permitindo pesquisas otimizadas através das metadatas (labels) dos logs.\n\nO Loki facilita a depuração e o diagnóstico de problemas em tempo real, permitindo a análise dos registros de serviços por tempo, labels e texto. Quando bem projetado, é possível identificar o erro recebido, o componente afetado, a função e o método da aplicação. Além disso, ele permite a criação de métricas em sistemas que não dispõem de outras ferramentas de monitoramento.\n\nNeste projeto, estamos coletando logs de INFO, WARN e ERROR de todas as rotas, seguindo o padrão [nome da função] - mensagem, por exemplo:\n\n- [session] - create: route executed\n\nQuanto às labels, estamos armazenando as seguintes informações:\n\n- application: watchdog-api\n- controller: Controller responsavel pelo log.\n- function: Função responsavel pelo log.\n- level: info | warn | error\n- method: Método da Requisição\n- rota: rota da API\n\nEsse padrão possibilita uma filtragem completa e eficiente dos logs registrados.\n\nPara mais informações, acesse a página do [Grafana Loki](https://grafana.com/docs/loki/latest/).\n\n\u0026nbsp;\u0026nbsp;\u0026nbsp;\n\n\u003ch3\u003e\u003cimg align=\"center\" width=\"50\" src=\"https://skillicons.dev/icons?i=grafana\" style=\"padding-right: 10px;\"\u003e Grafana\u003c/h3\u003e\n\nO Grafana é uma plataforma de visualização e monitoramento de dados que permite criar dashboards interativos, acompanhar métricas, visualizar e analisar logs em tempo real, além de criar alarmes baseados em métricas disponíveis. Ele suporta diferentes fontes de dados, como Prometheus, Loki, CloudWatch, Elasticsearch, entre outras.\n\nNeste projeto, utilizamos o Grafana para criar dois dashboards:\n\n- dash-watchdog-api: Um dashboard contendo painéis do tipo Time Series, Gauge e Stat, utilizado para monitorar em tempo real o estado da infraestrutura e da aplicação. As métricas deste dashboard são coletadas do Prometheus.\n- logs-watchdog-api: Um dashboard contendo painéis do tipo Logs e Time Series, utilizado para monitorar os logs gerados na aplicação Watchdog-API em tempo real. Além disso, disponibiliza algumas queries prontas para explorar e analisar os logs. Os dados deste dashboard são coletados do Grafana Loki.\n\nCom esses dois dashboards, torna-se mais fácil correlacionar eventos e realizar análises de erros com mais eficiência.\n\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"./images/gifs/grafana-interface.gif\" alt=\"Prometheus interface\" width=\"500\" style= \"padding-top: 10px;\"/\u003e\n\u003c/p\u003e\n\nPara mais informações, acesse a página oficial do [Grafana](https://grafana.com/docs/grafana/latest/).\n\n\u0026nbsp;\u0026nbsp;\u0026nbsp;\n\n\u003ch3\u003e\u003cimg align=\"center\" width=\"50\" src=\"./images/logos/jaeger-logo.png\" style=\"padding-right: 10px;\"\u003e Jaeger\u003c/h3\u003e\n\nO **Jaeger** é uma ferramenta de **tracing distribuído** utilizada para monitorar transações em arquiteturas distribuídas, desde aplicações monolíticas até microserviços. Ele permite acompanhar toda a **propagação transacional** dentro de um sistema por meio de **spans**, que juntos formam um **trace**.\n\nSimplificando, um **trace** representa uma transação do início ao fim, registrando todas as interações que ocorrem dentro desse fluxo. Cada interação é chamada de **span**, e ela contém informações como **tempo de duração**, **serviço responsável** e **relacionamento com outros spans**. Isso possibilita uma visão detalhada do percurso de uma requisição, incluindo:\n\n- Tempo total da transação\n- Tempo gasto em cada serviço ou componente\n- Dependências acionadas ao longo do fluxo\n\n**Uso no Watchdog API**\n\nNeste projeto, utilizamos o Jaeger para acompanhar a **malha transacional** desde o início da execução no **Nginx** até a finalização da transação. Conseguimos visualizar tanto a execução principal da função quanto o uso de componentes externos, como o **Loki**, permitindo uma análise mais detalhada do comportamento da aplicação.\n\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"./images/gifs/jaeger-interface.gif\" alt=\"Prometheus interface\" width=\"500\" style= \"padding-top: 10px;\"/\u003e\n\u003c/p\u003e\n\nPara mais informações, acesse a página oficial do [Jaeger](https://www.jaegertracing.io/).\n\n\u0026nbsp;\u0026nbsp;\u0026nbsp;\n\n## 🚀 Tecnologias\n\n\u0026nbsp;\u0026nbsp;\u0026nbsp;\n\n\u003ctable border=\"0\" align=\"center\"\u003e\n  \u003ctr\u003e\n    \u003ctd align=\"center\" width=\"100\"\u003e\n      \u003ca href=\"https://nodejs.org/en\" target=\"_blank\"\u003e\n        \u003cimg src=\"https://skillicons.dev/icons?i=nodejs\" width=\"50\"/\u003e\n        \u003cbr\u003eNode.js\n      \u003c/a\u003e\n    \u003c/td\u003e\n    \u003ctd align=\"center\" width=\"100\"\u003e\n      \u003ca href=\"https://expressjs.com/pt-br/\" target=\"_blank\"\u003e\n        \u003cimg src=\"https://skillicons.dev/icons?i=express\" width=\"50\"/\u003e\n        \u003cbr\u003eExpress\n      \u003c/a\u003e\n    \u003c/td\u003e\n    \u003ctd align=\"center\" width=\"100\"\u003e\n      \u003ca href=\"https://prometheus.io/docs/introduction/overview/\" target=\"_blank\"\u003e\n        \u003cimg src=\"https://skillicons.dev/icons?i=prometheus\" width=\"50\"/\u003e\n        \u003cbr\u003ePrometheus\n      \u003c/a\u003e\n    \u003c/td\u003e\n    \u003ctd align=\"center\" width=\"100\"\u003e\n      \u003ca href=\"https://github.com/prometheus/node_exporter\" target=\"_blank\"\u003e\n        \u003cimg src=\"./images/logos/node-exporter-logo.png\" width=\"50\"/\u003e\n        \u003cbr\u003eNode Exporter\n      \u003c/a\u003e\n    \u003c/td\u003e\n    \u003ctd align=\"center\" width=\"100\"\u003e\n      \u003ca href=\"https://prometheus.io/docs/alerting/latest/overview/\" target=\"_blank\"\u003e\n        \u003cimg src=\"./images/logos/alert-manager-logo.png\" width=\"50\"/\u003e\n        \u003cbr\u003eAlert Manager\n      \u003c/a\u003e\n    \u003c/td\u003e\n  \u003c/tr\u003e\n  \u003ctr\u003e\n    \u003ctd align=\"center\"\u003e\n      \u003ca href=\"https://grafana.com/docs/loki/latest/\" target=\"_blank\"\u003e\n        \u003cimg src=\"./images/logos/loki-logo.png\" width=\"50\"/\u003e\n        \u003cbr\u003eLoki\n      \u003c/a\u003e\n    \u003c/td\u003e\n    \u003ctd align=\"center\"\u003e\n      \u003ca href=\"https://www.jaegertracing.io/\" target=\"_blank\"\u003e\n        \u003cimg src=\"./images/logos/jaeger-logo.png\" width=\"50\"/\u003e\n        \u003cbr\u003eJaeger\n      \u003c/a\u003e\n    \u003c/td\u003e\n    \u003ctd align=\"center\"\u003e\n      \u003ca href=\"https://grafana.com/docs/grafana/latest/\" target=\"_blank\"\u003e\n        \u003cimg src=\"https://skillicons.dev/icons?i=grafana\" width=\"50\"/\u003e\n        \u003cbr\u003eGrafana\n      \u003c/a\u003e\n    \u003c/td\u003e\n    \u003ctd align=\"center\"\u003e\n      \u003ca href=\"https://docs.docker.com/get-started/\" target=\"_blank\"\u003e\n        \u003cimg src=\"https://skillicons.dev/icons?i=docker\" width=\"50\"/\u003e\n        \u003cbr\u003eDocker\n      \u003c/a\u003e\n    \u003c/td\u003e\n    \u003ctd align=\"center\"\u003e\n      \u003ca href=\"https://nginx.org/en/\" target=\"_blank\"\u003e\n        \u003cimg src=\"https://skillicons.dev/icons?i=nginx\" width=\"50\"/\u003e\n        \u003cbr\u003eNginx\n      \u003c/a\u003e\n    \u003c/td\u003e\n  \u003c/tr\u003e\n\u003c/table\u003e\n\n\u0026nbsp;\u0026nbsp;\u0026nbsp;\n\n## ⚠️ Pré-requisitos\n\n\u003e [!WARNING]\n\u003e Para executar o projeto é necessário instalar as seguintes ferramentas em sua máquina:\n\n- [Node.js](https://nodejs.org/en): v18 ou maior.\n\nPara o envio de alertas por e-mail, é necessário configurar credenciais. Se estiver utilizando uma conta do Gmail, será preciso gerar uma senha de aplicativo. Consulte a [documentação oficial do Google](https://support.google.com/accounts/answer/185833?hl=en) para mais detalhes sobre como criar essa senha.\n\n\u003e [!IMPORTANT]\n\u003e Renomeie o arquivo `.env_example` para `.env` e preencha as informações obrigatórias\n\n```\nALERT_EMAIL_TO=destinatario@gmail.com\nALERT_EMAIL_FROM=remetente@gmail.com\nALERT_EMAIL_USERNAME=remetente@gmail.com\nALERT_EMAIL_PASSWORD=aaaa bbbb cccc dddd\nSMTP_SERVER=smtp.gmail.com:587\n\nSECRET=hyper-mega-secret\nEXPIRE=43200\n```\n\n\u0026nbsp;\u0026nbsp;\u0026nbsp;\n\n## 📦 Instalação\n\nClone o repositório para o seu computador\n\n```\ngit clone https://github.com/MichaelDouglasPIX/watchdog-api.git\n```\n\nAccesse o projeto e instale as dependências\n\n```\ncd watchdog-api\nnpm i\n```\n\n\u0026nbsp;\u0026nbsp;\u0026nbsp;\n\n## 💻 Rodar o projeto localmente\n\n### Docker\n\nInicie os contêineres\n\n```\nnpm run docker:up\n```\n\nComando para finalizar a execução dos contêineres\n\n```\nnpm run docker:down\n```\n\nComando para reiniciar os contêineres\n\n```\nnpm run docker:reset\n```\n\n### Interfaces Web\n\nApós iniciar os containers com Docker, é possível acessar as interfaces de monitoramento para acompanhar e analisar os dados:\n\n- [Prometheus](http://localhost:9090/): Interface para consulta de métricas coletadas.\n- [Alert Manager](http://localhost:9093/): Gerenciamento de alertas configurados no Prometheus.\n- [Jaeger](http://localhost:16686/): Rastreamento distribuído de transações da aplicação.\n- [Grafana](http://localhost:3000/): Visualização de métricas e logs em dashboards personalizados.\n\n\u0026nbsp;\u0026nbsp;\u0026nbsp;\n\n\u003e [!WARNING]\n\u003e O container **request-generator** simula requisições de clientes, gerando tráfego para alimentar as métricas de monitoramento. Caso deseje visualizar apenas os seus próprios testes, você pode interromper esse container sem impactar o restante do projeto.\n\n\u0026nbsp;\u0026nbsp;\u0026nbsp;\n\n### Rotas da Watchdog API\n\nAbaixo estão as principais rotas da API, juntamente com suas descrições:\n\n| Método | URL                      | Descrição                                                                     |\n| ------ | ------------------------ | ----------------------------------------------------------------------------- |\n| GET    | http://localhost/        | Retorna um objeto JSON sem necessidade de body. json                          |\n| POST   | http://localhost/        | Requer um JSON contendo pelo menos um atributo.                               |\n| POST   | http://localhost/session | Requer um JSON contendo `username` e `password`                               |\n| GET    | http://localhost/latency | Simula uma latência aleatória entre 0 e 20 segundos e retorna um objeto JSON. |\n\n\u0026nbsp;\u0026nbsp;\u0026nbsp;\n\n## License\n\n[MIT licensed](LICENSE).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmichaeldouglaspix%2Fwatchdog-api","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmichaeldouglaspix%2Fwatchdog-api","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmichaeldouglaspix%2Fwatchdog-api/lists"}