日志文件

<?xml version="1.0" encoding="UTF-8" ?><configuration status="off" monitorInterval="1800"> <properties>　　　　　<!--路径--> <property name="LOG_PATH">./logs</property> 　　　　　<!--log路径--> <property name="LOG_NAME">strategy/oms-strategy</property> </properties> <appenders> <Console name="Console" target="SYSTEM_OUT" follow="true"> <PatternLayout pattern="%date{yyyy-MM-dd HH:mm:ss.SSS} %level [%thread][%file:%line] - %msg%n"/> </Console> <RollingRandomAccessFile name="running-log" fileName="${LOG_PATH}/${LOG_NAME}.log" filePattern="${LOG_PATH}/${LOG_NAME}.%d{yyyy-MM-dd}.log"> <PatternLayout pattern="

step1: 进入终端进入mysql： step2 : 开启mysql日志 set global general_log=on; step3 : 查看mysql的日志文件所在位置 show varibles like 'general_log_file'; step4 : 在终端中用tail -f 命令打开该日志文件： sudo tail -f /路径………… 来源： https://www.cnblogs.com/Leon27-29/p/12201437.html

oracle 监听启动后自动停止 场景:Windows环境下 oracle 11g数据库用的好好的 突然有一天数据库连不上了，检查发现监听未启动，于是启动监听， 用navicat发现连接不上（之前是正常的）但是命令行却可以正常连接数据库 排查原因： 检查配置文件 listener.ora 和 tnsnames.ora listener.ora： tnsnames.ora 这两个文件都没有问题！！！ 检查监听的日志文件 listener.log文件大小超过了4G ， 注意日志文件超过4G后监听就失效了，于是需要清理listener.log文件 解决方案： Windows环境下， 把oracle监听关闭，然后删除 listener.log文件 重启监听，数据库恢复正常！ ##删除 listener.log文件 重启监听后有可能会遇到下面情况： 原因是： listener.ora文件中 配置了多个监听，打开 服务列表，关闭oracle的其他监听 ， 然后再 删除listener.log文件 重新启动后数据库恢复正常！ 来源： CSDN 作者： 史庆杰 链接： https://blog.csdn.net/weixin_41377835/article/details/103988097

1 logging模块简介 logging模块是Python内置的标准模块，主要用于输出运行日志，可以设置输出日志的等级、日志保存路径、日志文件回滚等；相比print，具备如下优点： 可以通过设置不同的日志等级，在release版本中只输出重要信息，而不必显示大量的调试信息； print将所有信息都输出到标准输出中，严重影响开发者从标准输出中查看其它数据；logging则可以由开发者决定将信息输出到什么地方，以及怎么输出 2 logging模块使用 　　函数式简单配置 import logging logging.debug('debug message') logging.info('info message') logging.warning('warning message') logging.error('error message') logging.critical('critical message') 　　默认情况下Python的logging模块将日志打印到了标准输出中，且只显示了大于等于WARNING级别的日志，这说明默认的日志级别设置为WARNING（日志级别等级CRITICAL > ERROR > WARNING > INFO > DEBUG），默认的日志格式为日志级别：Logger名称：用户输出消息。 灵活配置日志级别，日志格式，输出位置: import

这是微软社区精英项目传过来的一个案例。 我当时给了解决方案。 问题描述： 环境说明： 操作系统 win2003 数据库 SQL SERVER 2000 SP4 数据库数据大小 150GB左右 具体故障描述： 连接门户系统 提示无法连接到配置服务器 去服务器本地查看 右下角提示 数据库所在的磁盘已满 于是把SQL服务停掉 该磁盘立即有十几GB的空间释放 重新启动SQL服务 连接门户系统 依然提示无法连接配置数据库 在SQL控制台连接该数据库也是连不上 门户系统共三台服务器 ： 10.205.1.6 应用系统服务器 SharePoint 10.205.1.7 门户DB 服务器 数据库服务器 SQL 2000 10.205.1.5 DC服务器 出现该错误的是10.205.1.7 数据库服务器 错误截屏: 解决方案: 这个问题初步看起来是SharePoint_Config和tempdb数据库的日志文件占用过大空间，以致于所在磁盘空间满了。 要解决这个问题，要稍微麻烦点。因为磁盘空间已满，SqlServer服务有可能无法正常启动。先不要让应用程序连接数据库，SharePoint也不要连接数据库。试着启动SqlServer服务。看看能否启动起来。如果不能，需要腾出来一点空间来。删除一些暂时不要的软件。总之要让SqlServer服务启动起来。如果SqlServer服务能起来，就做下面的。

nginx开启日志文件时启动网页服务出现以下报错 [root@localhost ~]# service nginx start nginx: [emerg] unknown log format "main" in /usr/local/nginx/conf/nginx.conf:41 是因为日志文件的main日志开启，可以选择删除main日志选项，或者开启log_format main选项 打开nginx配置文件 或者 完成上面配置即可开启 来源： 51CTO 作者： wx5d8a23dbc329e 链接： https://blog.51cto.com/14557736/2462418

[转]jstack Dump 日志文件中的线程状态 dump 文件里，值得关注的线程状态有： 死锁， Deadlock（重点关注） 执行中， Runnable 等待资源， Waiting on condition（重点关注） 等待获取监视器， Waiting on monitor entry（重点关注） 暂停， Suspended 对象等待中， Object.wait() 或 TIMED_WAITING 阻塞， Blocked（重点关注） 停止， Parked 下面我们先从第一个例子开始分析，然后再列出不同线程状态的含义以及注意事项，最后再补充两个实例。 综合示范一： Waiting to lock 和 Blocked 实例如下： "RMI TCP Connection(267865)-172.16.5.25" daemon prio=10 tid=0x00007fd508371000 nid=0x55ae waiting for monitor entry [0x00007fd4f8684000] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.log4j.Category.callAppenders(Category.java:201) - waiting to lock

引言 Linux以其稳定性，越来越多地被用作服务器的操作系统(当然，有人会较真地说一句：Linux只是操作系统内核:)。但使用了Linux作为底层的操作系统，是否我们就能保证我们的服务做到7*24地稳定呢？非也，要知道业务功能是由系统上跑的程序实现的，要实现业务功能的稳定性，选择Linux只是迈出的第一步，我们更多地工作是不让业务程序成为稳定性的短板。 当我们的服务器出现问题的时候，外在的表现是业务功能不能正常提供，内在的原因，从程序的角度看，可能是业务程序的问题(程序自身的bug)，也可能是服务器上人为的误操作(不当地执行脚本或命令)；从系统资源的角度看，可能是CPU抢占、内存泄漏、磁盘IO读写异常、网络异常等。出现问题后，面对各种各样可能的原因，我们应如何着手进行分析？我们有什么工具进行问题定位吗？ atop简介 本文要介绍的atop就是一款用于监控Linux系统资源与进程的工具，它以一定的频率记录系统的运行状态，所采集的数据包含系统资源(CPU、内存、磁盘和网络)使用情况和进程运行情况，并能以日志文件的方式保存在磁盘中，服务器出现问题后，我们可获取相应的atop日志文件进行分析。atop是一款开源软件，我们可以从 这里 获得其源码和rpm安装包。 atop使用方法 在安装atop之后，我们在命令行下敲入”atop"命令即可看到系统当前的运行情况： 系统资源监控字段含义

/*--> */ /*--> */ 介绍 本篇文章是对Innodb存储引擎的概念进行一个整体的概括，innodb存储引擎的概念是mysql数据库中最关键的几个概念之一，涉及的内容非常的广；由于个人的理解能力有限如果有不对的地方还见谅。 MySQL对应InnoDB版本 MySQL 5.1》InnoDB 1.0.X MySQL 5.5》InnoDB 1.1.X MySQL 5.6》InnoDB 1.2.X 后台线程 1.Master Thread 负责将缓冲池中的数据异步刷新到磁盘，保证数据的一致性；包括刷新脏页、合并插入缓冲、undo页的回收。 2.IO Thread innodb存储引擎中大量使用了AIO(Async IO)来处理写IO请求来提高数据库的并发性能，共有四类IO线程，分别是：insert buffer thread、log thread、read thread、write thread。其中read thread和write thread分别有四个线程，可以通过innodb_read_io_threads和innodb_write_io_threads来配置。 SHOW VARIABLES LIKE 'innodb_%io_threads' 或者 SHOW ENGINE INNODB STATUS \G; 3.Purge Thread线程 purge

前言 MySQL备份一般采用全库备份加日志备份的方式，根据业务的需要，可以采用每周日凌晨1点进行完全备份以及每小时进行一次增量备份，这样在MySQL故障后可以使用完全备份和日志备份尽可能的去恢复最完整的数据。 一、binlog日志恢复 MySQL的二进制日志记录着该数据库所有增删改的操作日志（前提是需要自己开启binlog），还包括了这些操作的执行时间，binlog的使用场景无外乎就是主从同步以及恢复数据库。开启binlog功能，需要编辑MySQL的主配置文件，如下： 1、查看二进制功能是否开启（如下，值为OFF，则表示未开启）： 2、开启二进制日志功能： [root@mysql ~]# vim /etc/my.cnf #在mysqld字段下写入下面配置，以便开启二进制日志并指定二进制文件名 #开启二进制日志，需要指定server-id，否则服务将会启动失败 log-bin=/usr/local/mysql/data/bin_log server-id=1 [root@mysql ~]# systemctl restart mysqld #重启后，将在指定的目录下生成两个文件，如下： [root@mysql data]# pwd /usr/local/mysql/data [root@mysql data]# ls | grep bin_log bin_log.000001