欄目導(dǎo)航

新聞資訊

新聞資訊

COMWIN 工程監(jiān)測采集儀常見問題土木工程、建筑工程及水利工程

工程監(jiān)測采集儀是一種常用于土木工程、建筑工程及水利工程等領(lǐng)域的儀器設(shè)備，常見問題如下：

儀器不穩(wěn)定：如果監(jiān)測儀器頻繁出現(xiàn)數(shù)據(jù)波動或不穩(wěn)定的情況，可能是因為儀器放置不平穩(wěn)或者受到干擾等原因。需要重新安置儀器位置或排除干擾因素。

數(shù)據(jù)不準(zhǔn)確：如果監(jiān)測儀器采集的數(shù)據(jù)不準(zhǔn)確，可能是因為儀器損壞、校準(zhǔn)不當(dāng)或者數(shù)據(jù)處理錯誤等原因。需要進行儀器維修，合理校準(zhǔn)和處理數(shù)據(jù)。

信號弱：如果信號弱，可能是由于電纜連接不良或者信號源太遠等原因?qū)е隆Ｐ枰獧z查電纜連接和信號源位置，確保信號通暢。

電池電量不足：如果儀器電池電量不足，可能會影響儀器正常運行。需要及時更換電池或充電。

操作不當(dāng)：如未按照說明書操作、使用不當(dāng)或誤操作等原因，可能會導(dǎo)致儀器損壞或數(shù)據(jù)不準(zhǔn)確。需要按照說明書正確操作監(jiān)測采集儀。

前言

sentry簡介

Sentry 是一款專業(yè)的企業(yè)級錯誤跟蹤和日志分析工具，旨在幫助開發(fā)人員、管理員和產(chǎn)品經(jīng)理跟蹤、分析和解決應(yīng)用程序錯誤和性能問題。

Sentry 的主要功能和優(yōu)點包括:

錯誤跟蹤: Sentry 可以跟蹤應(yīng)用程序中的錯誤，并將它們記錄下來，以便開發(fā)人員能夠快速定位和解決問題。

日志分析: Sentry 可以分析應(yīng)用程序的日志，并提供詳細的信息，如錯誤級別、調(diào)用堆棧、數(shù)據(jù)庫訪問等，以幫助開發(fā)人員快速定位和解決問題。

通知和警報: Sentry 可以通過電子郵件、Slack、PagerDuty 等渠道通知開發(fā)人員錯誤和性能問題的發(fā)生，以便及時響應(yīng)和解決問題。

可擴展性: Sentry 支持自定義錯誤消息、擴展錯誤跟蹤功能等，開發(fā)人員可以根據(jù)自己的需求進行自定義和擴展。

團隊協(xié)作: Sentry 支持團隊協(xié)作，可以方便地共享錯誤和日志信息，并支持多人同時編輯和評論。

總的來說，Sentry 是一款功能強大、易于使用的企業(yè)級錯誤跟蹤和日志分析工具，可以幫助開發(fā)人員和管理人員更好地管理和解決應(yīng)用程序中的錯誤和性能問題。

本文主要聊下在使用sentry過程中遇到的一些問題

問題錦集

問題一：uWSGI listen queue of socket "127.0.0.1:42563" (fd: 3) full !!! (101/100)

這是由于uWSGI的監(jiān)聽隊列滿了，默認(rèn)的監(jiān)聽隊列長度為100，把監(jiān)聽隊列調(diào)大就行

具體操作，修改/onpremise/sentry/sentry.conf.py

SENTRY_WEB_OPTIONS = {
    ....
    "listen":10240,
   ....
}

不過調(diào)了，重啟后大概率會報

Listen queue size is greater than the system max net.core.somaxconn (128)

此時要修改系統(tǒng)參數(shù)，如果是通過宿主機部署，則執(zhí)行vim /etc/sysctl.conf，添加如下內(nèi)容

# 用于設(shè)置內(nèi)核無法及時處理網(wǎng)絡(luò)接口收到的數(shù)據(jù)包時允許發(fā)送到隊列的最大數(shù)據(jù)包數(shù)目，默認(rèn)為128。也就是每個監(jiān)聽的socket，在沒有accept之前，等待處理的socket隊列長度
net.core.somaxconn = 10240

然后執(zhí)行sysctl -p 重新加載參數(shù)。不過如果是基于docker-compose部署sentry，這么加是沒效果的。得通過在docker-compose.yml做如下配置

示例：

version: '3'
services:
   ...:
    image: ...
    container_name: ...
    privileged: true
    sysctls:
      net.core.somaxcomm: '10240'

可以查看如下文檔
https://github.com/docker/compose/issues/3765#issuecomment-402929969

問題二：a client request body is buffered to a temporary file

在運行大概一周會，再次報

uWSGI listen queue of socket "127.0.0.1:43523" (fd: 3) full !!! (10241/10240)

說明隊列又滿了，于是看了nginx，出現(xiàn)問題二的錯誤，這個問題是因為客戶端請求體的緩沖區(qū)太小導(dǎo)致寫入臨時文件

因此可以通過配置如下參數(shù)

client_max_body_size 100m;
 client_body_buffer_size 10M;

將請求體緩存區(qū)大小調(diào)大。不過調(diào)了這個并沒解決

uWSGI listen queue of socket "127.0.0.1:43523" (fd: 3)

后邊調(diào)大uWSGI 線程數(shù)(默認(rèn)workers是4，thread是3)和keepalive（默認(rèn)是30s）時長，具體操作如下，修改/onpremise/sentry/sentry.conf.py ，根據(jù)系統(tǒng)的cpu核數(shù)，適當(dāng)?shù)恼{(diào)整workers數(shù)和thread數(shù)，示例配置如下

SENTRY_WEB_OPTIONS = {
   ....
    "so-keepalive": True,
    # Keep this between 15s-75s as that's what Relay supports
    "http-keepalive": 60,
    # the number of web workers
    "workers": 8,
    "threads": 8,
 
}

問題三：worker 3 lifetime reached, it was running for 86401 second(s)

程序運行大概一周后，不再報

uWSGI listen queue of socket "127.0.0.1:43523" (fd: 3) full

轉(zhuǎn)而報問題三的錯，后邊通過https://stackoverflow.com/questions/66489889/uwsgi-resets-worker-on-lifetime-reached-causes-downtime找到解決方案，就是將max-worker-lifetime改為 max-worker-lifetime-delta
具體原因可以查看
https://github.com/unbit/uwsgi/issues/2020

示例配置

修改/onpremise/sentry/sentry.conf.py

SENTRY_WEB_OPTIONS = {
    ....
    "max-worker-lifetime-delta":86400,
   ....
}

至此sentry運行了大半年都沒出現(xiàn)上述問題

總結(jié)

本文主要是記錄在使用sentry過程中，遇到的問題，為什么會記錄，因為我在排錯的過程中，我一開始是去官方github看issues，看有沒有解決答案，其中看到要么是純理論要么是建議升級版本，通過搜索引擎查了一些資料，也試了很多，發(fā)現(xiàn)沒解決問題，或者看似解決了，后面又復(fù)現(xiàn)了。于是就寫了這篇文章，一來可以復(fù)盤一下，二來是希望可以幫助到有出現(xiàn)類似問題的伙伴

欧美vvv,亚洲第一成人在线,亚洲成人欧美日韩在线观看,日本猛少妇猛色XXXXX猛叫

前言

問題錦集

總結(jié)