@zedpass syslog 可以通过 /etc/syslog.conf （或者 rsyslog.conf ）来配置，但……这是系统全局配置，肯定又要 root 的。

@zedpass “zabbix 的告警脚本”是什么意思？是你从 zabbix 外部独立运行这个脚本，还是会在 zabbix 运行时触发？
前者的话跟 zabbix 没有任何关系，只是你从心理上觉得适合“统一放到 zabbix 目录下”而已。如果是后者，（我不懂 zabbix ，按一般情况推理）那运行时是以 zabbix 身份启动的，那一般不是很建议自己搞日志，应该通过 zabbix 提供的机制……如果没有的话，真是个人畜无害的小白花纯脚本，需要自己来搞日志，那也不应该放到 /var/log/zabbix 下。

另外，你这个话题提供的 context 不太足，让人没办法判断。你在这个工作里是什么角色？服务器拿不到 root ，那我按一般情况推理来假设，你应该不是这个服务器的“法定”运维管理人……那应该去找对应的人协商应该怎么办。是给你权限，还是由对方部署，还是按对方的要求把日志文件写到指定的地方……总之靠你在 v2 就这么没有 context 地莫名其妙发一帖，别人又不知道你的实际情况，没法给出准确的建议。

一般来说，“我没有服务器 root 权限”这事不是个纯粹的技术问题。它的本质是“我并不是所在的组织机构里认可的能合规管理这台服务器的人”，是人的职权问题。操作系统里帐号、文件系统的权限，只不过是管理策略落实到技术上的投影。你首要该做的是把职权的障碍打通。

著名的 啊，老年 web 开发者都知道的

你的脚本又不是 zabbix 的一部分，为什么要往 /var/log/zabbix 下写东西？

遇到过一次类似的，以后我配的对公服务 nginx 的默认 server context 都是直接返回 451

往好里想，ISO 那帮人搞了个不切实际的 OSI 网络七层模型，互联网圈子🐦都不🐦它一眼

@theklf4 我想说的意思是，一个由学生民间组织建起来的服务网站是某大学里所有单体网站流量最大的，只有网站群才超过它，这事本身就是意义，意义是真的有人用。
至于括号里那些，是为了注明我在这里用单体网站这个词所表示的网站范围，不是为了讨论谁比谁流量大奇怪不奇怪。你可以当这段不存在。

我校的镜像站是全校所有单体网站（也就是排除用于建立各单位新闻型门户网站的那个“网站群”建站系统）里流量最大的

对于完全不懂运维知识又要硬上生产环境的开发人员来说，大部分其它 web 开发语言写的系统到生产环境部署确实比 PHP 复杂。但是要上生产环境，运维知识是避不开的，不论是自己学还是别人学了跟你分工。

Kong 企业版会在国内直接面向企业用户销售或者通过做企业信息化实施的厂家集成销售吗？——来自一个用了好几年 Kong 开源版并且最近在评估 APISIX 的传统行业信息化人员

喜欢 Consolas 又要用非 Windows 系统可以试试开源仿制品 Inconsolata

还不是你们（我们）惯出来的毛病

另外，HTTP API 给 web 前端浏览器里用 JS 调用和给第三方应用系统的后端调用也是两种不同的场景，对最佳实践的选择也有影响。

如果发生错误，是与业务逻辑无关的系统错误（不论是客户端还是服务器，自己方还是外方），还是与系统无关的业务错误？前者表明系统没毛病，是用户操作的错，要由用户解决，并且允许出现的常态；后者表明用户操作没毛病，是系统的错，由技术人员（某方的开发或运维）来解决，即使发生的频率不低也不应该视为允许出现的常态。有些错误很容易分辨出属于哪一类，而有些就需要技术和业务都精通的老司机才能准确分辨。HTTP 状态码和 body 数据之争的本质是，针对这两类错误如何设计报错机制。

@iyaozhen 屁股决定脑袋。你所谓的对业务的监控，是指想知道业务挂了，这个问题本来就属于基建。我也说了，如果业务系统里发现有基建问题，硬生生抓住包成一个 200 抛回给调用方，这个我也不能接受的。但很多莱塞特福原教旨主义者想要做的是把业务逻辑层面的错误也给放到 HTTP 状态码里，比如一个大学生离校系统里要去查学生在各个单位的业务是否已结清，我一个图书馆系统的接口发现还有书没还的时候，给他返回 HTTP 200 再加一个 JSON 表示业务层面这个操作不成功，但我的系统没挂，调用方传进来的参数也符合 schema ，权限也对，所以在 HTTP 层面我认为没问题，不应该返回错误码……有人说这样不清真，应该改成在 HTTP 码里把这个当“错误”来返回，不能塞进 200 的 JSON 里。这不是扯鸡巴蛋吗。总不会有人为了方便监控离校系统调用图书馆系统接口时的业务逻辑错误率而想把我千奇百怪的业务错误码从 JSON 里提出来放到 HTTP 状态码吧。

当然，我坚决反对 JDBC 连不上数据库服务器的时候抓出来异常还要包到 200 里向上返回……业务逻辑上的错误（责任在甲乙方最终用户，不涉及基础设施运维）用 200 包起来返回是一个美丑的问题，基础设施错误还要这么搞，是沙雕还是沙壁的问题。

至于拿监控说事的……监控啥？

如果是为了监控基础设施，我 JSON 里封的是业务逻辑层面的错误，关你基础设施屁事？

如果是为了监控业务错误，却嫌错误代码封在 JSON 里不方便……你就是想让我把业务错误代码放到 HTTP 里去对吧？你是不是觉得我这边各种各样的业务错误怎么映射到 HTTP 那几个状态码里很简单？你个普罗米修斯崽懂个屁的业务。

我的业务 API 又不只是为了让你来做监控而存在的，我要给别的业务单位调用啊。HTTP 状态码没出错，业务状态码出错的时候，可以去找管业务系统的人处理，HTTP 状态码出错了找管基础设施的人处理，这两拨人不是同样技能的啊。业务端有个什么狗屁错（而且还不是那种 unrecoverable 的外部环境错，是业务逻辑的错，要业务用户处理的）都返回成 HTTP 错误码一级一级传上去，查个业务级错误都要基础设施的人联动，这是制造民怨吗？你来给我做基础设施架构让我有办法一键定位出错的层次和节点吗？可是我只能拿到够做业务功能的经费，而且是单个单个项目做，没有做基础设施的条件，我让一个行业人士起家的地方性行业性中小型业务信息化开发商给我做业务系统开发的时候顺便免费做一套云原生的微服务的可观测的可这个那个狗屁的基础设施，并且以后的其它同类业务开发商要逼着他们不允许用自己的积累，一定要做在这些所谓现代的平台上，这忒外祖母的现实吗？