Логирование lua в syslog

#linux #логирование #lua

Как напрямую писать логи с Openresty Lua в syslog?

При установке библиотеки luasyslog возникает ошибка:

ng-gateway_1  | error loading module 'vendors.lsyslog' from file '/usr/local/openresty/site/lualib/vendors/lsyslog.so':
ng-gateway_1  |     /usr/local/openresty/site/lualib/vendors/lsyslog.so: undefined
symbol: luaopen_vendors_lsyslog


Подскажите как решить проблему, или какую библиотеку использовать.
Спасибо!
    

Ответы

Ответ 1

Было принято решение писать в syslog сервера на уровне nginx.

В docker-compose в volumes добавил bind на локальный /dev/log:

- type: bind
    source: /dev/log
    target: /dev/log


В nginx.conf, директиве server прокинул 2 unix socket-а:

# Logging configurations
error_log  syslog:server=unix:/dev/log,tag=ng_trace;
access_log syslog:server=unix:/dev/log,tag=ng_trace,nohostname;


Для логирования в lua использую ngx.log(ngx.ERR, 'Log message')

Все логи из докер-контейнера пишутся прямиком в syslog сервера.


Ответ 2

Openresty не пользовал, поэтому за правильность ответа - не ручаюсь. По приведенным
логам ситуация похожа на не согласование версий. Возможно отрывок из FAQ Openresty
ситуацию прояснит: 


  ** Why can't I use Lua 5.2 or later? **
  
  Lua 5.2+ are incompatible with Lua 5.1 on both the C API land and the Lua land
(including various language semantics). If as you said there are quite a few people
already using ngx_lua + Lua 5.1, then linking against Lua 5.2+ will probably break
these people's existing Lua code. Lua 5.2+ are essentially incompatible different languages.
  
  Supporting Lua 5.2+ requires nontrivial architectural changes in ngx_lua's basic
infrastructure. The most troublesome thing is the quite different "environments" model
in Lua 5.2+. At this point, we would hold back adding support for Lua 5.2+ to ngx_lua.
Also, we do not want to create confusions and incompatibilities on the Lua land for
applications running atop ngx_lua, as well as all the existing lua-resty-* libraries
written in the Lua 5.1 language.
  
  We believe it is better to stick with one Lua language in ngx_lua. Chasing the
Lua language's version number has not many practical technical merits (if there were
some political ones).


Резюме: смотрите версию используемого Lua