Anyone successfully sending syslog to victoria-logs app?

I am trying to use the victoria-logs app to receive and store remote syslog from RouterOS (the same device running the container).

This is a RB5009, ROS 7.22.3 with an external SSD connected over USB.

I am still working my way through a full understanding of how an app configuration results in a container configuration, but I believe the crux of my issue is as follows. The victoria-logs app sets up UDP port 514 for syslog, and creates the firewall port forward, however port 514 is never exposed to the (internal) network so it can never receive the forwarded packets.

In comparison to technitium, which is similar to victoria-logs in that it has a web interface and a service port, technitium's app yaml contains the following port spec:

    ports:
      - "5380:5380:web" #DNS web console (HTTP)
      - "53:53/udp:dns" #DNS service
      - "53:53/tcp:dns" #DNS service

Once the app is running, the container's JSON lists these exposed ports:

    "ExposedPorts": {
      "443/tcp": {},
      "443/udp": {},
      "53/tcp": {},
      "53/udp": {},
      "53443/tcp": {},
      "5380/tcp": {},
      "67/udp": {},
      "80/tcp": {},
      "8053/tcp": {},
      "853/tcp": {},
      "853/udp": {}
    },

By contrast, the victoria-logs app yaml has a similar ports spec (also including the following command property for illustration):

    ports:
      - 9428:9428:web
      - 514:514/udp:syslog
    command: -syslog.listenAddr.udp=:514 -syslog.useRemoteIP.udp=true

... but victoria-logs's running container only indicates the web port as exposed:

    "ExposedPorts": {
      "9428/tcp": {}
    },

I think this is arguably a bug in the app configuration that MikroTik ships, or potentially in how app yaml is documented. I notice two important details about the information provided above:

  1. Technitium exposes far more ports than are listed in the app configuration.
  2. The victoria-logs app passes an explicit configuration command to listen for syslog at UDP port 514.

This suggests that there is a difference between the yaml ports property as documented and the actual behavior. For reference, the documentation for port in app yaml says the following:

ports | Port mappings in format host:container:protocol
...
How This Example Works
4. Port Exposure: Maps TCP and UDP port 5201 (iperf3's default port) to the host

Technitium is only supposed to expose three ports, however the ports actually exposed are the ones stored in the docker image itself -- for example, view the docker image layers on dockerhub and click layer 20 (EXPOSE [443...) and then scroll back up to see the complete command:

EXPOSE [443/tcp 443/udp 53/tcp 53/udp 53443/tcp 5380/tcp 67/udp 80/tcp 8053/tcp 853/tcp 853/udp]

That's the full list of ports that actually get exposed by the container to the internal app/container network.

By contrast, the explicit mention of UDP port 514 for syslog in victoria-logs's app yaml command property would suggest that this is not a default behavior of the container image since it is being deliberately passed. We can confirm this again on dockerhub: the image only exposes 9428/tcp and the app yaml ports field has NO effect on the ports exposed by the running container.

Can anyone with more experience with apps say if there is a way to force additional port exposure from the container runtime to the host? Or is this even available in /container/add?? (Doesn't look like it to me...) If not, then I believe the only way to do this properly is to make a custom image that includes UDP port 514 in an EXPOSE directive. (In standard docker CLI you can do a docker run -p 514:514 ... as an alternative to docker run -P ... which just exposes all ports declared in the dockerfile.

Ignore all of the above.

RouterOS's container implementation doesn't use EXPOSE or ExposedPorts whatsoever. The ExposedPorts values in the container JSON are just the inspection properties of the container image, not the ports exposed by the running container.

My actual problem is probably hairpin NAT as I am currently successful in sending logs to victoria-logs from a different RouterOS device.