输入法不显示解决办法
长久以来，很多朋友出现输入法莫名其妙的不见了，很多人还说基本可以确认自己没有删除、修改系统配置，基本可以确定没有中病毒，可以说是在前一天还正常使用的输入法再次开机的时候突然不见了。今天有图小站给出一些解决办法，从前到后可能越来越难，或者越来越不容易碰到，你可以逐步尝试，希望对你有所帮助。
1、首先确认一下简单的调用是否还有效，即使用CTRL+空格是否有反应。很多朋友安装了、，或者紫光输入法之后将其他的删除，造成输入法暂时性消失，但使用CTRL+空格可以调出剩下唯一的中文输入法。
2、在任务栏单击鼠标右键单击，弹出菜单中选择 工具栏 ，然后看 语言栏 是否被选中，如果没有选中，单击选中 语言栏。
3、打开控制面板（ 开始 &控制面板 &或者 &开始 & 设置 &控制面板 ），单击 日期、时间、语言和区域设置 ，单击 语言和区域设置 ，在弹出 语言和区域设置 对话框中单击 语言 标签，在 文字服务和输入语言 下单击 详细信息 按钮，弹出 文字服务和输入语言 对话框，单击 高级 标签，在 系统配置 下，把 关闭高级文字服务 前面的对号取消（看到下面的注释了没有，选中 会关闭语言栏 ），单击 确定 按钮，输入法图标就回来了（这个是目前出现最多的，使用此法可以不少问题）。
&4、点 开始 运行 ，键入 msconfig ，单击 确定 ，在 启动 里把 Ctfmon.exe 选中，单击 确定 ，重新启动，输入法大部分可以出来。ctfmon.exe文件是系统输入法配置文件，很多朋友在优化加速系统的时候，将其去掉（手工运行去掉或者是使用360、卡卡等清理工具将其清理出启动项目），现在所要做的是将其重新选中。（这个是输入法问题也出现较多的情况）
5、先进行第4种解决办法，然后进行第3种解决办法。
6、临时的方法，直接 开始-运行 ，输入ctfmon.exe（Win2000/98输入internat，此处不是internet），此法可以印证是否是此文件没有启动所引起的问题，也就是说是否可以按照4来进行。
7、如果第6种方法中出现 Windows找不到文件ctfmon 或者第4中方法无效，可能是输入法文件ctfmon.exe丢失或者被病毒破坏（文件被篡改）。这时需要从一个同批次操作系统的计算机上复制一个ctfmon.exe文件，然后执行第4种解决办法，多数情况即可。这个输入法文件的位置在 C:\windows\system32 下。
有图给出一个下载，（仅用于xp），解压缩后，放到将ctfmon.exe文件复制到 C:\windows\system32 下，执行一遍第4种方法，确认ctfmon.exe 随计算机启动，重新启动计算机即可。以上是输入法不见的解决办法。
8、如果第以上方法均无效，很抱歉，你很有可能需要重新安装操作系统了。
原创，原地址
转载请保留。
关于 输入法不显示解决办法 你可能还会阅读：
有图小站关注电脑、网络技术的分享，主要记录自己的工作和遇到问题的解决办法，少量转载他人高质量内容。如你觉本站有用，请收藏或告诉朋友一起看。想了解更多请点击。邮箱： QQ群：VAT included in all prices where applicable.&&
View mobile websiteGIT_DIR=/home/gerrit/gerrit_data/git/check_mk.git/ git show master:.werks/1103GIT_DIR=/home/gerrit/gerrit_data/git/check_mk.git/ git show 1.2.8:.werks/1103GIT_DIR=/home/gerrit/gerrit_data/git/check_mk.git/ git show master:.werks/1093GIT_DIR=/home/gerrit/gerrit_data/git/check_mk.git/ git show 1.2.8:.werks/1093GIT_DIR=/home/gerrit/gerrit_data/git/check_mk.git/ git show master:.werks/266GIT_DIR=/home/gerrit/gerrit_data/git/check_mk.git/ git show 1.2.8:.werks/266
Monitoring Windows with Check_MK
Letzte Aktualisierung: 09. November 2011
1. The Windows Agent
Check_MK provides its own agent for monitoring Windows hosts: check_mk_agent.exe.
This agent is being installed as a Windows service and has several advantages
over the NSClient++ (besides that fact that it supports Check_MK, of course):
Minimalistic approach - one single executable file, no DLLs or additional files needed.
Shipped with source code - compilable with the free compiler . You do not nee proprietary software for re-compiling the agent.
On current Linux distributions you can even cross-compile the agent on Linux.
Support for monitoring Windows Eventlogs.
Security: the agent never reads any data from the network and thus is not
endangered by code insertion attacks.
Extensions can be written in arbitrary programming languages.
And last but not least: No configuration is needed.
Where to find
The Windows agent will be installed into a directory that is configurable during
setup of Check_MK. When using OMD you will find the agent in the directory
via share/check_mk/agents/windows below your site directory.
3. Installation of the agent
3.1. The windows agent installer
Beginning from version 1.1.13i3 there is an installer available for the Windows
agent. For installing the windows agent using this new installer simply download the windows
installer or copy the check-mk-agent-&version&.exe from the agent
directory of your Check_MK installation to your Windows host and start it.
The installer will ask where to install and whether or not it should install and
start the windows service. The default options should fit most users needs, so you can
simply click through the installer.
By default the agent will be installed to %PROGRAMFILES%\check_mk. When
the installation is finished, the service has been created and started. You can
start monitoring your Windows host right away.
The installer supports some command line arguments which are:
/Sruns the installer or uninstaller silently
/D=sets the default installation directory. It must be the last parameter used in the command line and must not contain any quotes, even if the path contains spaces. Only absolute paths are supported. You need to set the path like this: /D=C:\path\to\agent
3.2. Manual Installation of the agent
If you don't like to use the agent installer you can also install the windows
agent manually. The installation of the agent is easy. Just copy
check_mk_agent.exe to your Windows host into a convenient directory
and call it from a command shell with the option install:
C:\some\directory\> check_mk_agent.exe install
This will install a new Windows service called Check_MK_Agent. This service
can be started with the Windows service manager or simply by entering:
C:\some\directory\> net start check_mk_agent
If the agent is running properly you should be able to connect
to the Windows host to TCP port 6556 from the Nagios host. You
can test this, e.g., with telnet:
user@host:~$ telnet windowshost 6556
&&&check_mk&&&
Version: 1.1.13i1
AgentOS: windows
WorkingDirectory: C:\some\directory
ConfigFile: C:\some\directory\check_mk.ini
AgentDirectory: C:\some\directory
PluginsDirectory: C:\some\directory\plugins
LocalDirectory: C:\some\directory\local
OnlyFrom: 0.0.0.0/0
&&&uptime&&&
3.4. Integration into check_mk
The integration of Windows hosts is nothing special and goes the usual
way: add the host to all_hosts in main.mk and
run the inventory with cmk -I. After that update
your Nagios configuration files with cmk -U and
restart Nagios:
4. Trying out the agent without installing it
The check_mk_agent allows you to try it out without installing it as
a service. The simplest way is to call it with the option test.
This does not open a TCP socket but simply displays all current data on
your console:
C:\some\directory\> check_mk_agent.exe test
&&&check_mk&&&
Version: 1.0.29rc
[System Process]
winlogon.exe
Another option is to start the agent with the option adhoc.
No it will open TCP port 6556 and handle requests just like
the service. It will do so until you abort it by pressing Control-C:
C:\some\directory\> check_mk_agent.exe adhoc
Listening for TCP connections on port 6556
Close window or press Ctrl-C to exit
5. Information provided by the agent
As of version 1.1.12 the agent provides access to the following data:
Size and usage of all fixed disks
All running processes
All running and stopped services
Usage of RAM and the page file
CPU utilization
Disk IO (throughput)
All Eventlogs found in the system
The system time (time synchronization)
Length of message queues of MS Exchange
Furthermore checks can be added by making use of
external plugins written in VBS, command or other
languages. Currently we ship the following plugins:
Active directory replication
DHCP Pools
Windows Multipathing
Windows Updates
Ressource usage of processes via WMI
The agent can be configured to output arbitrary Windows performance counters. Check_MK currently
only extracts disk throughput, CPU usage and MS Exchange queues. Further checks can
be implemented without any changes to the agent.
6. Configuring Checks in main.mk
Most of the items to be checked are found by the inventory function.
want to autodetect processes and services as well, some configuration in main.mk
is needed.
6.1. Processes
The output of the Windows agent is compatible with that of the
Linux and UNIX agents with respect to the processes. Please
refer to &&.
6.2. Services
In order to monitor services you need first to determine
which services are of interest to you. The easiest way
is to look at the raw output of the agent and look for
the section &&&services&&&. You
can use cmk -d for this:
user@host:~$
cmk -d winhostxy | fgrep -A 10 '&&&services&&&'
&&&services&&&
Warndienst
Gatewaydienst auf Anwendungsebene
Anwendungsverwaltung
Windows Audio
Intelligenter Hintergrund&bertragungsdienst
Computerbrowser
Check_MK_Agent
Check_MK_Agent
Indexdienst
Ablagemappe
COM+-Systemanwendung
The first column of the output is the exact internal name of the
service. Let's say you want to check if ALG is running on
host winhostxy. Then put the following line into your
checks variable:
checks = [
( 'winhostxy', 'services', 'ALG', None ),
# some other checks...
If you have a larger number of windows hosts it is a tedious
and error prone work to define which services you expect for each
host. Check_mk helps you by providing an inventory
mechanism for services. All you have to do is to provide
a list of relevant services. This list is global and needs
to be defined only once in main.mk in the
variable inventory_services.
During the next inventory of windows hosts, check_mk scans
for these services and automatically
creates a check for each one found running.
Lets assume that the services TSMListener, Httpd and
TapiSrv should always be monitored if found running on a machine.
All you have to do is to add to your main.mk:
inventory_services = ['TSMListener', 'Httpd', 'TapiSrv' ]
At the next inventory all hosts where that services run will
be detected and checks created automatically.
If you need more flexibility, such as:
regular expression matching
taking the start type of a service into account (auto, demand, ...)
using host tags in order to make rules for only a certain group of hosts
then please refer to the
for details.
Eventlog Monitoring
The Windows agent sends output that is fully compatible with that
of the Linux/UNIX agent and is
thus handled in the same way. For sake of simplicity there are nevertheless some
differences:
The agent does not save its state persistently to disk.
The agent does not filter messages, but uses the fact that Windows
classifies messages into Informational, Warning
and Error. The agent sends all non-informational messages.
What does this mean in detail? When the agent is started (most probably
at boot time of the host) it will try to seek to the current end of
the Eventlogs and wait there for new records. Only records appearing
while the agent is running will be sent to Nagios. If the agent is stopped
and started again, it theoretically could miss some messages. As the
agent is running permanently this should not be a practical problem, though.
Since the agent is completely configuration-less it does no specific
filtering of events. It simply looks for messages of type
Warning or Error. If such a message is seen, the complete
check interval will be declared as relevant. The agent sends
all messages of the logfile that appeared since the
previous check to Nagios - even those of type Information. This allows
the administrator to have more context information about the problem
at hand on the Nagios server.
If you want to suppress some messages or reclassify them from
Warning to Critical or vice versa, you can define a message
filter in main.mk. This is done by setting the
variable logwatch_patterns which is a Python dictionary
with a key for each logfile. The value is a list of pairs:
logwatch_patterns = {
'System': [
( 'W', 'sshd' ),
( 'W', 'rebooting.*system' ),
( 'C', 'path link down' ),
( 'I', 'ORA-4711' )
'Application': [
( 'W', 'crash.exe' ),
( 'C', 'ssh' ),
( 'I', 'test.*failed' )
All patterns for a logfile are executed from first to last. The first
match wins. The entry ( 'W', 'sshd' ) reclassifies all messages
containing sshd to Warning. There are three possible
C: reclassify as CRITICAL
W: reclassify as WARNING
I: ignore these messages
Note that the patterns are regular expressions. Thus the entry
( 'I', 'test.*failed' ) reclassifies all messages containing
the word test and later the word failed.
Messages that do not match any pattern retain their classification
from the agent. Messages that are classified as context messages
by the agent are never reclassified.
7.1. Host specific filtering of messages
As of version 1.0.37 of check_mk, host specific message filtering
is supported. This means that you can have your reclassification in
logwatch_patterns depend on the host where the message
has been found.
Host specific patterns include a host list, or a host tag list and
a host list as first elements of the entry. This works quite similar
to many other configuration variables. Please read more about
for details on that. The following example makes some of the patterns
of the upper example host specific:
logwatch_patterns = {
'System': [
# reclassify only on host abc123
( [&abc123&], 'W', 'sshd' ),
# the following holds for all hosts
( 'C', 'path link down' ),
# reclassify message to &ignore& on all hosts with the tag &test&
( [&test&], ALL_HOSTS, 'I', 'ORA-4711' )
'Application': [
# Do not reclassify on host &testhost&
( [&!testhost&], 'W', 'crash.exe' ),
# make ssh critical on &dmz& hosts that do not have the tag &test&
( [&dmz&, &!test&], ALL_HOSTS, 'C', 'ssh' ),
# this is for all hosts again
( 'I', 'test.*failed' )
7.2. Advanced agent configuration
The eventlog monitoring of the Windows
agent can be configured to your needs. For each eventlog you can decide which
messages should be sent to Check_MK. The default is that all eventlogs
are processed and messages of the types warning or critical (or security
failures) are being sent.
If you create a file called check_mk.ini in the agent directory,
you can configure which eventlogs and which levels are processed.
Here is an example:
It is also possible to suppress the context messages for windows eventlogs
with the option nocontext. Here is an example:
check_mk.ini
[logwatch]
# From the Application log send only critical messages
logfile application = crit
# From the system log only send warning/critical messages,
# but suppress any context messages
logfile system = warn nocontext
# Do not process other event logs at all
logfile * = off
Note: When setting a logfile to all, also informational
messages are being sent. As long as you do not reclassify them via logwatch_patterns,
those message will nevertheless not trigger any alarm.
Setting a logfile to off will disable processing of that
eventlog. Reading application specific eventlogs can have an impact
on the stability of the agent if the application has bugs in their eventlog
implementation.
8. Logfile monitoring
Besides the Windows event logs you can also monitor plain text log files.
You need to configure these in check_mk.ini, of course.
For this feature use the section logfiles. Here is an example
check_mk.ini
[logfiles]
textfile = C:\temp backup\Testfile*.txt | D:\tmp\info.log
warn = hostA? WARN*
crit = *invalid line*
ignore = User * logged in
ok = *Backup created*
crit = *emergency*
textfile = C:\Windows\logins.txt
warn = *Access error*
crit = *Password error*
ignore = *successfully logged in
The textfile field determines the files to be monitored. Multiple files
in one line are separated by |. Patterns may be used with the globs
After the textfile patterns the corresponding state patterns are defined.
in the unix version the available states are warn, crit, ok and ignore.
1.2.5i6 windows agent: now able to omit context text of logfilesYou can now configure whether the context of the logfiles should be
sent too, if a ok/warn/crit logline was detected within the logfile.
The context includes lines starting with '.' (default context) or 'I' (ignored lines).
A new option nocontext has been introduced for the logfiles section in the check_mk.ini file.
check_mk.ini
[logfiles]
# The following textfile will not report any context info (nocontext option)
textfile = nocontext C:\tmp\memo.udf
# Set patterns for defined textfile
warn = *overdue*
ok = *mail sent*
If you simply prepend the parameter nocontext to the actual path (or path pattern),
all files matching this pattern will exclude any context info.
9. Performance Counters, monitoring MS Exchange
Several Windows checks are based on Performance Counters. These are
special objects provided by the Windows operating system that contain
information about throughput, queue lengths, latencies and other numbers
of the system and applications like MS Exchange.
Performance counters are grouped into Counter Objects. Within
the operating system each object has a unique ID. Unfortunately IDs for
applications (like MS Exchange) are not fixed but vary from server
to server. In the registry there is a translation between those number
and names - but the names are in the local installation language and thus
not portable either. This is very sad. And it makes some configuration
neccessary if you want to make use of all of the agent's features.
One good thing is - however - that some basic counter objects seem
to have fixed IDs. This is at least the case for the counters needed
for monitoring the CPU utilization and the disk throughput.
Check_MK ships ready-to-use checks for
CPU utilization
Disk throuphput per physical disk
MS Exchange mail queues
If you want to make use of the MS Exchange checks, you first have to
determine the ID of the counter object MSExchangeTransport Queues.
In order to find that, first open a command box (DOS box) and dump
the complete counter information into the file counters.ini:
C:\& lodctr /s:counters.ini
Now you can view this file with Notepad or use find on
Windows - which does essentially the same as grep on Linux -
and watch for MSExchangeTransport Queues:
C:\& find &MSExchangeTransport Queues& counters.ini
---------- COUNTERS.INI
[PERF_MSExchangeTransport Queues]
10332=MSExchangeTransport Queues
If you prefer analysing the file under Linux, you first need to convert
it to UTF-8 (it is UTF-16 litte-endian encoded!). This can be done on
Linux with:
user@host:~$ recode UTF-16LE..UTF-8 counters.ini
In this example the ID of the counter object is 10332. The
ID can now be configured in check_mk.ini. Create this file
in the same directory where check_mk_agent.exe is installed,
with the following content:
check_mk.ini
counters = 10332:msx_queues
Now restart the agent. When you retrieve the agent output from
your monitoring host, you should now get an additional section
&&&winperf_msx_queues&&& with
a content similar to this one:
cmk -d YOURHOST
&&&winperf_msx_queues&&&
1 instances: _total
2 0 rawcount
4 0 rawcount
6 0 rawcount
8 0 rawcount
10 0 rawcount
12 0 rawcount
14 0 rawcount
16 0 rawcount
18 895 rawcount
20 895 counter
22 0 rawcount
24 0 counter
Now when you inventorize the host with cmk -I, new
checks for several MS Exchange mail queues should appear. For details
please consult the man page of .
1.2.5i6 windows agent: performance counter can now be specified by nameIt is no longer required to set a performance counter id in the check_mk.ini file
check_mk.ini
counters = 10332:msx_queues
You can now use the counter name instead
check_mk.ini
counters = MSExchangeTransport Queues:msx_queues
Note: Keep in mind that this name depends on you system language.
If available, the windows agent tries to find the counter name in the registry key.
SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Perflib\\CurrentLanguage
If this key is missing, the english language key is used as fallback
SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Perflib\\009
10. Extending the Windows agent
10.1. Plugins and local checks
From version 1.1.7i3 the Check_MK agent for windows can be
extended just as the Unix agents with
and plugins.
Local checks are (usually simple) scripts or programs performing self written
checks and computing the results directly on the target machines.
Plugins are scripts or programs that output agent sections similar to those
builtin in the agent. Several such scripts are shipped together with the
agent and are found in the subdirectory plugins.
In order to use such plugins you need to:
Create a directory plugins in the same directory where you have put
check_mk_agent.exe (on your windows hosts)
copy the plugins in question into that directory
make sure the system account the agent is running on has appropriate permissions
for running the checks
One example of such a plugin is wmicchecks.bat, which uses wmic in
order to list processes with their ressource consumption:
wmicchecks.bat
echo ^&^&^&wmic_process:sep^(44^)^&^&^&
wmic process get name,pagefileusage,virtualsize,workingsetsize,usermodetime,kernelmodetime /format:csv
In order to make use of this agent information your installation of Check_MK needs
a check which can process that data. The checks needed for the shipped plugins are
part of Check_MK. A tutorial for writing your own checks can be found .
WARNING: Windows' concept of launching other programs as subprocesses is sometimes
hard to grasp for people used to Unix-like operating systems. So please make sure that there are
no files in your local or plugins directory that are executable
or that open a window when being executed. The latter is particularly true when a text file
is found: Windows will then open notepad.exe as a subprocess of the agent on the Windows
console. As long as notepad is running the agent is hanging and cannot even be killed
or restarted. The solution in such a case is (in order to avoid a reboot):
Remove the critical file(s) from the local and plugins directory.
Go to the windows console. This might involve being physically present at the server.
Close the notepad or whatever window had been opened.
Note: The agent does not execute all files in local and
plugins, but first checks the file name extension. Per default
all files except those with the suffix txt or dir are
being executed. If you want you can specify an explicit list of extensions
to execute. This is done in the optional file check_mk.ini in the
[global] section:
check_mk.ini
# Execute only files with the following extensions
execute = bat exe vbs ps1
Note: these settings are not being honored by MRPE (see below).
10.2. MRPE
Check_MK's Windows agent also supports , MK's remote plugins executor.
MRPE allows you to run classical Monitoring plugins
locally on a Windows host and gives you access to hundreds of checks ready to use
that float around in the Internet.
MRPE on Windows does not make use of an own configuration file but uses check_mk.ini.
You should put The plugins you want to execute into the section [mrpe] using the following format:
check_mk.ini
# Run classical Nagios plugins. The word before the command
# line is the service description for Nagios. Use backslashes
# in Windows-paths.
check = Dummy mrpe\check_crit
check = IP_Configuration mrpe\check_ipconfig 1.2.3.4
check = Whatever c:\myplugins\check_whatever -w 10 -c 20
They check_crit dummy is shipped with Check_MK and can be used for
your tests. It simply fails with a Nagios state of CRITICAL and displays
one line of text.
Please note that just like in the Unix version of MRPE, the service description
must not contain spaces.
1.2.5i1 windows_agent: now supports MRPE include filesThis version introduces the mrpe configuration option include.
With this option you can define addiontal include files and the user domain in
which include files should be executed.
check_mk.ini
# Run classical Nagios plugins. The word before the command
# line is the service description for Nagios. Use backslashes
# in Windows-paths.
check = Dummy mrpe\check_crit
check = IP_Configuration mrpe\check_ipconfig 1.2.3.4
check = Whatever c:\myplugins\check_whatever -w 10 -c 20
# Additional mrpe configs
# The include files can be changed during the runtime
include \\ab = C:\includes\ab_mrpe.cfg
include \\NT-AUTORIT?T\SYSTEM = C:\includes\system_mrpe.cfg
# If you omit the user the file is executed with the current user
include = C:\includes\default.cfg
The syntax in the mrpe include file is the same as in the mrpe section, with the exception
that you cannot add further includes in a include file. There is also no need to define a [mrpe]
section in an included file. You just need to define the check lines here.
ab_mrpe.cfg
check = Dummy mrpe\check_crit
check = IP_Configuration mrpe\check_ipconfig 1.2.3.4
Important: Keep in mind that the agent needs the permission to run
scripts as other user. Internally it uses the windows command runas /User:
which prompts for a password if agent has no permission to change to this user.
In this case the check_mk agent will get stuck!
11. Timeouts, caching and parallel processing of local and plugin scripts 1.2.3i2
Since version 1.2.3i2 it is possible to uncouple the local and plugins
script execution from the main process.
Previous versions had problems whenever the executed scripts took very long or
never returned due to programming errors. This caused the agent to hang indefinitely
until the responsible script was terminated.
11.1. Basic principle
Starting with version 1.2.3i2 scripts are now executed in separate threads.
The job of these threads is to collect the script output and make it available to the main thread.
Whenever the agent is queried by the monitoring server, it can now instantly access the cached data
from the worker threads. This results in a greatly improved agent response, since the agent no
longer has to wait for any scripts to finish.
However, there is a small downside: The data is determined in advance, so the information is
slightly outdated - with a maximum of one check cycle.
You can still choose not to enable this feature for certain scripts and force the agent to wait for them
to finish - just like in previous versions.
Moving the local and plugin checks into different threads opens up plenty of configuration options.
11.2. New local and plugin configuration options
Within the [local] and [plugins] sections you can now set these
new configuration parameters
execution 1.2.3i7
This parameter specifies when a script should be executed. Whether during the agents runtime (sync)
or later on (async) after the agent data has been sent.
Any data from scripts with async mode will be available on the next agent call.
The default setting is sync.
This parameter specifies how long a script is allowed to run until the
process gets terminated. In this case the script delivers no output at all, thus leading
to a missing section in the agent output. The default value is 60.
retry_count
This parameter allows a script to fail multiple times (e.g. due to a timeout)
before its cached data is discarded and no script output is returned. The default value is 0.
Generally a local or plugin script should be able to finish in a reasonable amount of time.
If it occasionally hangs for some unknown reason it might be a good idea to increase the
retry_count for this script.
This parameter signalizes that the cached data can be reused for the specified time.
As long as the script output is new enough, there is no need to start the script again.
The default value is 0.
This is especially useful for scripts which cause high cpu load on execution or simply do not
provide meaningful new information within those short query timeframes.
For those scripts you could set the cache_age to 3600, so that the script's
cached data is only updated once an hour.
The following example shows some basic configuration for local and plugin scripts.
Each line in the [local] and [plugins] section has this syntax:
{type} {script pattern} = {value}
Like in the other configuration sections you may use glob expressions for the script patterns.
check_mk.ini
# Default timeout is 60 seconds
# Default cache age is 0 seconds (no caching)
timeout mem_info.bat = 10
timeout * = 30
# Default timeout is 60 seconds
# Default cache age is 0 seconds (no caching)
timeout wmic_if.bat = 5
# the windows updates plugin is executed in async,
# has a timeout of 120 seconds
# and is only updated every 3600 seconds
execution windows_updates.vbs = async
timeout windows_updates.vbs = 120
cache_age windows_updates.vbs = 3600
# All other scripts have a cache age of 120 seconds,
# their data is discarded if the script fails 3 times
# and have a timeout of 10 seconds
cache_age * = 60
retry_count *.bat = 3
timeout * = 10
11.3. Local and plugin data collection settings
As mentioned before, the output of the scripts is now stored into caches which are read
by the main process. There are two distinct ways of collecting these data, each having their pros and cons.
Parallel script execution
With parallel script execution all local and plugin scripts are executed at the same time.
Pro:Overall script execution duration is smaller when using multiple scripts.
Con:Might cause high CPU load
Queued script execution
With queued script execution all local and plugin scripts are executed one after each other.
Pro:Lower CPU load
Contra:If one script hangs, all other scripts are delayed.
To circumvent this, you might specify a maximum timeout for those scripts
Since 1.2.3i7 it is possible to set the execution method async_script_execution
for scripts which are configured to run in async mode.
This execution mode sets whether the scripts are executed sequential or parallel.
check_mk.ini
async_script_execution = sequential
The following values are available
sequential
The async scripts are executed one bye one.
The async scripts are executed all at the same time.
Any output of scripts configured with the async is delayed by one check cycle, usually one minute.
12. General agent configuration
12.1. Restricting Access
As of version 1.1.9i1, the Check_MK agent for Windows allows for access restriction
based on IP addresses - just like xinetd for Linux. If you
want to make use of this feature you need to create a configuration file
check_mk.ini in the same directory as the agent.
The restriction is configured by the variable only_from in the
section [global]:
check_mk.ini
only_from = 127.0.0.1 10.0.0.0/16 192.168.56.17
You may add up to 32 IP addresses or networks in slash-notation. If
you do not configure only_from or leave it empty, all clients
are allowed.
Make sure to restart the agent after any change of the configuration
C:\some\directory\& net stop check_mk_agent
C:\some\directory\& net start check_mk_agent
Please note that the agent cannot inhibit the initial TCP connect, because it cannot
check the IP address of the remote site before the connection is accepted. If
a disallowed remote host has connected, the agent immediately closes the
connection. The client thus sees a successful initial connection followed by a
'connection closed by foreign host' without reading any data.
This is exactly the way xinetd behaves.
You can also define matching scopes in the "windows firewall with advanced security" or IP Security rules.
12.2. Sections to execute
For the purpose of finding problems or speeding up the agent you can configure, which sections should be executed.
This is accomplished in the [global] section with the configuration option sections.
sections = check_mk uptime ps df mem
In order for Check_MK to get general information about the agent, you
should always enable the section check_mk.
12.3. Host specific configuration
Depending on how you manage your windows servers you might need host-specific
configuration settings in check_mk.ini.
Check_MK offers a method
for keeping settings for different hosts in a single check_mk.ini
that can be distributed to all of your hosts.
Let's look at the following example:
host = zmsex?? zexchange*
counters = 10332:msx_queues
The directive counters = 10332:msx_queues will only be executed on hosts
with a name beginning with zexchange or those made of zmsex and
two further characters. The jokers * and ? can be used like
for filenames. Any number of patterns can be added after the host = .
This restriction holds until the end of the section:
# Counters for some selected hosts
host = zmsex0? zexchange*
counters = 10332:msx_queues
# Counters for some other hosts
host = zmsex1?
counters = 10320:msx_queues
[logwatch]
# This will be executed for all hosts:
logfile * = off
You also can switch off the restriction by setting a filter for *:
[logwatch]
# Logfiles for hosts ending in prod:
host = *prod
logfile security = warn
# This holds for all hosts:
logfile application = off
Note: hostname matching is case insensitive.
12.4. Crash-Debugging
Some users have reported that on some few Windows servers
they have seen the Check_MK agent crash from time to time. The new
global option crash_debug helps in such a case. Add this
to your [global] section and set it to on.
crash_debug = yes
This will enable error logging during the computation of the
agent sections:
Before a new client connection is accepted a file connection.log
will be created. After the connection is closed this file will be renamed
to success.log.
If the agent starts and sees a connection.log lying around it
assumes that it previously has crashed. It will rename this file to
crash.log. Before, it will rename any existing crash.log
to crash-1.log, that one to crash-2.log and so on
up to crash-9.log.
A new subjection of &&&logwatch&&& will be
created simulating a new event log file
In case of a previous crash the contents of the crash.log will
be visible in this logfile and thus be transported to your monitoring
server where you can see the famous last words of the agent.
Do the following steps when trying to investigate an agent crash:
Set crash_debug = yes in check_mk.ini
Restart the agent
Do an inventory of that host with Check_MK. This will create
a new service LOG Check_MK Agent.
Restart Check_MK and you monitoring server in order to make the check active
Wait for the next crash
Navigation
11. Timeouts, caching and parallel processing of local and plugin scripts 1.2.3i2
Verwandte Artikel}