is there anyway to trace the messaging flow in edgeHub?
i have two modules that connect sensors (the opc-ua publisher) and a coap proxy and i am routing them to the cloud with
"all2hub": "FROM /messages/* INTO $upstream"
That works fine and I can see the telemetry from both devices
If i add another module that does nothing but writes to the console every message it receives with
"all2test": "FROM /messages/* INTO BrokeredEndpoint(\"/modules/tester/inputs/test\")"
I don't get a single message coming to the test module...I wonder if I could trace and see what is happening....
You can enable debug logs for edgeHub by adding RuntimeLogLevel environment variable with value debug to the deployment (from the portal go to Set modules -> Configured advanced Edge runtime settings)
Another way to enable debug logs is by updating the IoT Edge security manager config file
Replace env: {} with
env:
RuntimeLogLevel: debug
Save the file and restart the IoT Edge security manager.
With debug logs enavled you should check edgeHub logs if messages are received and sent.
Related
iotedge list command error
Hi,
On running the iotedge list command it is throwing - A module runtime error occurred. Is there something missed. It was working fine till yesterday.
If you are still blocked, you can check the below information.
There could be multiple reasons for the module runtime error on IoT Edge.
Was it working earlier and stopped suddenly? As Matthijs mentioned in
the comments, collect complete logs to know more about the issue.
Refer Gather debug information with 'support-bundle' command
Also, check Azure IoT Edge security manager logs. The IoT Edge
security manager is responsible for operations like initializing the
IoT Edge system at startup and provisioning devices. If IoT Edge
isn't starting, the security manager logs may provide useful
information.
Make sure that the module is properly configured and all
required environment variables are set.
If the issue still persists, you can try restarting the module or the
entire IoT Edge device to see if that resolves the issue.
You can also check Solutions to common issues for Azure IoT Edge for most common errors and solutions.
I have been using Kafka Connect in my work setup for a while now and it works perfectly fine.
Recently I thought of dabbling with few connectors of my own in my docker based kafka cluser with just one broker (ubuntu:18.04 with kafka installed) and a separate node acting as client for deploying connector apps.
Here is the problem:
Once my broker is up and running, I login to the client node (with no broker running,just the vanilla kafka installation), i setup the class path to point to my connector libraries. Also the KAFKA_LOG4J_OPTS environment variable to point to the location of log file to generate with debug mode enabled.
So every time i start the kafka worker using command:
nohup /opt//bin/connect-distributed /opt//config/connect-distributed.properties > /dev/null 2>&1 &
the connector starts running, but I don't see the log file getting generated.
I have tried several changes but nothing works out.
QUESTIONS:
Does this mean that connect-distributed.sh doesn't generate the log file after reading the variable
KAFKA_LOG4J_OPTS? and if it does, could someone explain how?
NOTE:
(I have already debugged the connect-distributed.sh script and tried the options where daemon mode is included and not included, by default if KAFKA_LOG4J_OPTS is not provided, it uses the connect-log4j.properties file in config directory, but even then no log file is getting generated).
OBSERVATION:
Only when I start zookeeper/broker on the client node, then provided KAFKA_LOG4J_OPTS value is picked and logs start getting generated but nothing related to the Kafka connector. I have already verified the connectivity b/w the client and the broker using kafkacat
The interesting part is:
The same process i follow in my workpalce and logs start getting generated every time the worker (connnect-distributed.sh) is started, but I haven't' been to replicate the behaviors in my own setup). And I have no clue what I am missing here.
Could someone provide some reasoning, this is really driving me mad.
TL,DR; Log levels are ignored when making a Stackdriver logging API call using using a CloudLoggingHandler from a Docker container using the Google Cloud Logging driver.
Detail;
The recommended way to get logs from a Docker container running on Google's Compute Engine is to use the Stackdriver Logging Agent:
It is a best practice to run the Stackdriver Logging agent on all your
VM instances. The agent runs under both Linux and Windows. To install
the Stackdriver Logging agent, see Installing the Logging Agent.
The following steps were completed successfully:
Ensure Compute Engine default service account has Editor and Logs Writer roles.
Ensure the VM instance has Cloud API access scope for Stackdriver Logging API (Full)
Install and start Stackdriver Logging Agent.
I then copied the example CloudLoggingHandler example from Google's Cloud Platform Python docs.
import logging
import google.cloud.logging
from google.cloud.logging.handlers import CloudLoggingHandler
client = google.cloud.logging.Client()
handler = CloudLoggingHandler(client)
cloud_logger = logging.getLogger('cloudLogger')
cloud_logger.setLevel(logging.INFO)
cloud_logger.addHandler(handler)
cloud_logger.error('bad news error')
cloud_logger.warning('bad news warning')
cloud_logger.info('bad news info')
The Docker container is started with the Google Cloud Logging Driver flag (--log-driver=gcplogs):
sudo docker run --log-driver=gcplogs --name=server gcr.io/my-project/server:latest
This works, however all logs, irrespective of level are only visible in Stackdriver when viewing 'Any log level'. Strangely, the message itself contains the level:
2018-08-22 22:34:42.176 BST
ERROR:bad news error
2018-08-22 22:34:42.176 BST
WARNING:bad news warning
2018-08-22 22:34:42.176 BST
WARNING:bad news info
This makes it impossible to filter by level in the Stackdriver UI:
In the screenshot below, all icons on the LHS of every log entry show the level as Any:
From what I can tell, the CloudLoggingHandler is a standalone handler that sends logs to the Global log level. To integrate with gcplogs driver properly, try using the ContainerEngineHandler
I am able to configure an agent for window but i have a confusion regarding connectivity between web servers logs with agent.
1: How to connect web server with agent ?
2: while starting flume.bat file. It is generating flume.log file in which i am getting below mentioned Exception.
org.apache.flume.conf.ConfigurationException: No channel configured for sink: hdfssink
at org.apache.flume.conf.sink.SinkConfiguration.configure(SinkConfiguration.java:51)
atorg.apache.flume.conf.FlumeConfiguration$AgentConfiguration.validateSinks(FlumeConfiguration.java:661)
1.The data flow is as below
your application (or web server) --> source --> channel --> sink
Now, the data can flow from your webserver to the source either by "pull" mechanism or "push" mechanism. In your case, you can either tail the webserver logs or use a spooling source.
2.This looks like a misconfiguration issue. You need to post your config file to figure out the issue
Is anyone successfully using MsDeploy for deploying windows services with a preSync runCommand? I've got it working using an Administrator account, but can't for the life of me get it working on a standard user account. Unfortunately I can't use integrated authentication (we're deploying to an external box), and the thought of our Administrator password sitting in plaintext in logs on our build server doesn't exactly make me feel too comfortable. For that matter, neither does any user credentials - but I can't see a way around that.
The command I'm using is this:
"tools/deploy/msdeploy.exe" -verb:sync
-preSync:runCommand="tools\Deploy\PreSyncCommand.cmd",waitInterval=30000
-source:dirPath="C:\BuiltSourcePath"
-dest:computerName=https://server:8172/msdeploy.axd?site=dummysitename,userName=service-deploy,password=service-deploy-pass,authType=basic,dirPath="C:\DeployPath\"
-allowUntrusted
with rules set up in IIS for the dummy site to allow the authentication for the service-deploy windows account, with contentPath and runCommand permissions (for the moment set to C:\ as it's not entirely clear whether this needs to be set to the temporary path that MsDeploy streams to, or the deployment path?). The service-deploy account also has full control of the target directory. I get the following back:
Performing '-preSync'...
Info: Using ID '7a7d34a1-b5d8-49f1-960a-31c9cf825868' for connections to the remote server.
Info: Using ID '4d0b910c-aca4-4640-84bd-3597d22d99d1' for connections to the remote server.
Info: Updating runCommand (C:\TeamCity\buildAgent\work\aec989676b349656\tools\De
ploy\PreSyncCommand.cmd).
Warning: Access is denied.
Warning: The process 'C:\Windows\system32\cmd.exe' (command line '/c "C:\Windows
\ServiceProfiles\LocalService\AppData\Local\Temp\giz2t0kb.0ay.cmd"') exited with
code '0x1'.
This happens even if the contents of PreSyncCommand.cmd is blank. The same command runs fine if I pass in Administrator credentials. I've tried using ProcessMonitor to check if anything's being denied access but can't see any - so I'm guessing it's still a MsDeploy authentication rule. There's nothing in WmSvc.log (debugging is enabled), nor in the event log.
Any ideas? Thanks!
Since you're using Web Deploy via WmSvc, you need to setup appropriate delegation rules on the destination server:
Within IIS Manager, open the "Management Service Delegation" feature. Add a new rule which at least specifies the runCommand provider. In the Run As section, choose Specific User and provide credentials for a local administrator account on that machine. This is the identity under which your runCommand scripts will be executed. Finally, the user which you're specifying for the destination dirPath provider needs to be added to the delegation rule.
That allows you to invoke a deployment using a non-privileged account, and yet have it executed on the target machine under administrative credentials.
More information on IIS feature delegation: http://learn.iis.net/page.aspx/516/configure-the-web-deployment-handler/