手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜的Vultr , 注册 | 登陆
浏览模式: 标准 | 列表全部文章

找了台4c8g的机器装了sentry

sentry这个东西吧,你要不用它,其实也可以只是用它的话呢,你能收集到更详细的信息。平时的错误日志可能是会散的,比如你nginx访问返回500,这时候你还得看程序出错的异常,对应那个时间段 。然后如果当时记录的信息不够详细,你还要倒推,请求了哪些参数,能不能复现,这些参数有没有更方便的请求,带了哪些cookie,有没有session。烦

有了sentry之后呢,这些出错信息,自然也就都带过来了。至少看到出错日志的时候,我能够知道出错行数、出错内容、请求来源、以及请求的参数。甚至还有curl的代码给你。让你可以模拟请求进行复现。
 
为了装sentry。真的是很痛苦。因为之前买的小鸡都一般是2c4g。对于开发Web来说,2c4g足够了。但sentry要求,至少4c8g,20G空间。20G空间是小事。。。但4c8g真的太贵了。。。腾讯轻量云年购老用户5.5折都要1680一年了。心痛啊。
 
不过看在他可以收集:flutter、vue以及laravel的错误日志上,我还是购了一台。毕竟网页里的vue出错了。我没法让用户告诉我你打开f12把错误信息截个图我。。
 
先试试看用一年再说了。为自己的线个项目都建一个project。看看能不能改善现在的开发情况。
---
本来也想用官方的服务的,但sentry.io有时候访问还得爬梯子,速度也不尽如意,创建项目也没有那么多。所以才想了自建,就是成本高了点
 

Tags: sentry

rpm数据库修复

因为偷懒,在腾讯云上使用的时候,就直接用了bt面板的镜像,这个镜像用的是centos,也因此就有了yum 和rpm数据库的问题。

因为某次在更新的时候嫌慢,所以直接ctrl+c,然后。。。再次启动的时候就:
 yum update
错误:rpmdb: BDB0113 Thread/process 8643/139904725112896 failed: BDB1507 Thread died in Berkeley DB library
错误:db5 错误(-30973) 来自 dbenv->failchk:BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery
错误:无法使用 db5 -  (-30973) 打开 Packages 索引
错误:无法从 /var/lib/rpm 打开软件包数据库
CRITICAL:yum.main:
 
Error: rpmdb open failed
 
---看这个样子,就是数据库坏了。
看起来没什么特别好的办法,只能重建,于是:
# mkdir /var/lib/rpm/backup
# cp -a /var/lib/rpm/__db* /var/lib/rpm/backup/
# rm -rf /var/lib/rpm/__db.[0-9][0-9]*
# rpm --quiet -qa
# rpm --rebuilddb
# yum clean all
 
yum clean all运行完后会显示 :
已加载插件:fastestmirror, langpacks
Repository epel is listed more than once in the configuration
Repodata is over 2 weeks old. Install yum-cron? Or run: yum makecache fast
正在清理软件源: centos-sclo-rh epel extras os updates
Cleaning up list of fastest mirrors
 
至此,修复完毕,因为用的腾讯云,所以直接将源切到腾讯:CentOS (tencent.com),先用yum version看看版本,然后下载相应的repo。最后运行:
yum clean all
yum makecache
 
世界清静了
 
 

引入unplugin-auto-import无效

 前段时间用React,这段时间用Vue3(用uniapp写小程序的时候也尝试切换到vue3了),本来觉得很累的,毕竟在每次使用都要import {vue} from 'vue'之类的,在使用了unplugin-auto-import插件后,真的少写了好多。但也要看unplugin-auto-import是不是支持。

 
比如我现在直接引用了vue,象现在onMounted/ref等都不再定义了。
 
然而刚开始的时候却是怎么都没法用,这时候才发现虽然我代码都是用JS写的,但auto-import插件是ts写的,必须要引入typescript组件,然后他才生成一个:auto-imports.d.ts的文件,这时候配合<script setup>这个所谓vue3的黑魔法,才是妥妥的。
 
没什么大东西,就是这么记录一下

华为平板M5的webview的一个BUG

用flutter的webview来展示一个数据页面,因为这个页面如果用原生开发,得费不少时间,而且中间还要显示图表,也可能随时要调整,所以最后改用了webview。

项目是检测内容的结果,因为要检测七大类,每个类都有一个图表和相应的数据呈现,但因为设计稿已经预先有了外框结构,因此内嵌的这个webview的宽度大约在800左右 ,触发了tailwind的sm的效果。所以原来一个检测结果 两列显示的,变成了一列,也因此400左右的高度的,变成了800左右,而有7个项目,则成了5600的高度。
利用webview的jschannel,在resize获取到高度后通过postmessage发送回flutter,flutter获取高度后再setState一下。看起来没差,在小米上很轻松的就显示了。但华为的机器就是不行。中间一块黑屏。
查看LOG,发现一堆bindTextureImage的错误,抛的异常也是Exception updateTextImage,可是我页面上并没有TextImage,所以就开始怀疑Webview了。之前为什么没有怀疑呢,就是因为其他页面上的webview是正常的。
1、将元素中用到Image的先屏蔽一下,仍然报错
2、将webview禁用,无错
3、打印postmessage的值,发现是49xx左右 ,于是强制设定webview的高度为1024,正常
4、不停调整webview的高度,直到3200左右直接黑屏
5、本来在考虑是否用Scrollbar,但事实上因为这个页面的设计稿正好将检测报告放在正中,四周都有内容,不方便全屏到底
最后,将检测报告改用tabbar的HTML来展示 。这样单个Tabbar的高度就算扩展到1000左右也不影响显示,经过测试一切正常。
 
华为这台机器真LOW啊,然后查了一下,海思960s,还是960的降频版,内存4G,鸿蒙2.0,用了大概3小时,无故大崩了3次,其中2次重启一次是refresh。虽然这是2~3年前的机器,但这也太。

navicat连接腾讯云轻量数据库的一个小坑

 买了腾讯云的轻量数据库,便宜(其实现在和直接买1c1g的数据库也差不多了)。在做数据迁移的时候直接用了navicat的data transfer(这功能真方便)

因为数据库不大,只有2~300M,用datatransfer走起来非常快。基本上3分钟左右 就搞定了。如果我dump sql,再upload & import sql,反而比这个速度还要慢一点。
然后问题就来了,查询的时候,全是乱码,这个很明显,是latin1的问题了,于是上数据库 执行了一下:SHOW SESSION VARIABLES LIKE 'character\_set\_%';果然 
character_set_client latin1
character_set_client_handshake ON
character_set_connection latin1
character_set_database utf8mb4
character_set_filesystem binary
character_set_results latin1
character_set_server utf8mb4
character_set_system utf8
这个就纠结了,即使我set names utf8mb4,用datatransfer也是这个问题。
我导数据过来的那一台,也是轻量级数据库,理论上不应该会有这个问题,于是我看一下connection的相关信息。发现正常的那台,encoding居然选的是auto,而这台不正常的选择的是utf-8,难道是因为这个原因?于是切回auto重连。
再次运行SHOW SESSION VARIABLES LIKE 'character\_set\_%';果然 character_set_client 已经恢复成utf8mb4了。
 
这个问题也真是妖~