Monitoring via elastic beats?

We have a separately hosted elastic cloud instance for monitoring, and I’m attempting to get some of our render services to ship logs there. Is there a recommended way to do something like this? I was trying to create a metricbeat docker service in render (along the lines of this Run Metricbeat on Docker | Metricbeat Reference [7.12] | Elastic), and point that at a render db or service via the config.

Haven’t been able to work yet, so wondering if I’m headed down the right track or if there’s a better way

Hi @mgrip,

I haven’t used Metricbeat, but it definitely seems like something that should work on a Render service. You might need to configure your application to redirect logs to somewhere that Metricbeat can monitor.

We’re also working on support custom syslog endpoints in the coming weeks. I’m not familiar with your hosted solution, but it may support shipping logs to a syslog endpoint, which would make it fairly simple. I’m not sure exactly when this will be available, or how well it’ll fit your solution, though, so I’d definitely encourage you to move forward trying to get Metricbeat set up.

The syslog endpoint definitely sounds like it would be helpful, thank you :+1:. I’ll keep investigating the metricbeat as a service route for now, thanks!

Actually @dan I’m running into something that I hope is a simple fix - I managed to get this kind of working, but metricbeat is recording/shipping logs during the “build” phase, but never actually switches over to “live”, and eventually the build just times out. Maybe I’m missing something around the pserv config?

Here’s the bit from my render.yaml
# metricbeat
- type: pserv
name: metricbeat
env: docker
repo: -repo link-
branch: master
plan: standard
name: mc
property: connectionString

…and here’s the metricbeat Dockerfile
COPY metricbeat.yml /usr/share/metricbeat/metricbeat.yml
USER root
RUN chown root:metricbeat /usr/share/metricbeat/metricbeat.yml
USER metricbeat

Hi @mgrip ,

The service type you’ve chosen, pserv (or private service), is intended as a service that will listen on port 10000 and serve traffic. It looks like the service is timing out because metricbeat is never listening on the port, so Render things the service has never gone live.

The worker service type is what you’re looking for if you want something to not serve traffic. Check out our docs on background workers for more info: Background Workers | Render · Cloud Hosting for Developers

One thing that catches my eye is that you’re deploying metricbeat as its own service. If my understanding is correct, you’ll want metricbeat to monitor logs of some other process, so you’ll want both to be running in the same service. If that’s the case, you’ll want to have one service that runs both metricbeat and your other process, and you’ll need to coordinate running both of those processes in your Dockerfile’s CMD or ENTRYPOINT.

Ah got it that makes total sense. Switched to a worker and its working great!

I think you’re right about us eventually wanting to move this into each actual service that we’d want to monitor - I think that would be a pretty big change though since we have a Postgres DB and web services using the ruby environment that would both need to switch to Docker? For now I’m just pointing to those via the “hosts” param that metricbeat allows you to configure, which seems to be working ok over the private network render sets up.

Oh, yeah, if they can just point to other services on the same private network, then that’s great. Probably easier than trying to integrate it into each service.

thanks for the help! I’ll keep an eye out for the syslog endpoint too, sounds like that will come in handy