By default, ETW events produced by SF services are available through VS tooling. They are not available via Service Fabric Explorer. What are other (external to VS) tools can be used to consume those events?
A few options here:
Azure Diagnostics
https://azure.microsoft.com/en-us/documentation/articles/service-fabric-diagnostics-how-to-setup-wad/
the (preview) Service Profiler
https://www.azureserviceprofiler.com/
(I think it works for Actors only at this time though, but it's already a very cool tool, worth having a look at)
(as mentioned) Elastic Search
https://azure.microsoft.com/en-us/documentation/articles/service-fabric-diagnostic-how-to-use-elasticsearch/
(etw data needs to be collected and transferred in every option)
You can use Elastic Search or Kibana
Related
I have a service fabric application that hosts api’s with app insights enabled. The api services are .Net framework 4.8 webapi projects and they are native fabric stateless and stateful services. I don’t use the app insights service fabric specific packages, but do have the standard app insights for webapi packages. I have always been in Azure commercial and logs have worked just fine there.
Now that we are in azure gov, the only way to point a .Net Framework app to the gov app insights endpoints is by modifying the ApplicationInsights.config file.
So I’ve modified the file as per msdn, verified it is deployed with the fabric deploy package and its there next to the rest of the dlls on the vms. Yet my services still won’t log to azure gov app insight instances. Nothing is coming through. We set the instrumentation key programmatically, not in applicationinsights.config, could that be an issue? I noticed some of the msdn examples showed instrumentationkey being included in the config file, but would think that is optional.
Had anyone had experience pointing .net 4.8 fabric services to gov app insights?
When using a government cloud, you need to use a connection string instead of an instrumentation key.
Important
Sovereign clouds, such as Azure Government, require the use of the
Application Insights connection string
(APPLICATIONINSIGHTS_CONNECTION_STRING) instead of the instrumentation
key. To learn more, see the APPLICATIONINSIGHTS_CONNECTION_STRING
reference.
More info here and here.
This ended up being an issue with my gov configuration file. The MSDN document wasn't very clear on where the new config sections go. It made it look like they are all nested under the top level node of the config file. Turns out the TelementyChannel override has to go inside the default TelemenySinks node. I contacted microsoft on github about clarifying this in their docs.
Link to the unclear documentation
https://learn.microsoft.com/en-us/azure/azure-monitor/app/custom-endpoints?tabs=net
Link to github issue to get it fixed
https://github.com/MicrosoftDocs/azure-docs/issues/80066
There's lots of documentation and a kludgy console to set up continuous deployment in Cloud Foundry, but I haven't found any documentation on what the artifacts inside a repository need to be.
I don't want to cut-n-paste flows from the node red editor. If that's the only way, then IBM is not ready for prime time. I also am aware of most everything about my flows being in the Cloudant nodered db.
A node red application is more than the flows though. What about my _design docs for my dbs?
I need device info and other stuff from the Watson console, Cloudant info and my flows packaged up into something deployable.
Has anyone scripted this?
What I mean by this is I can clone a Docker project, an npm project and all sorts of projects that implement a build->test->push mechanism. They employ a configuration script of some sort (e.g. package.json) and contain a bunch of source files for the actual application, test scripts, db scripts, whatever is necessary to deploy the application and its environment into a host. I see lots of documentation on the toolchain and its features, but I'm not clear on if it's possible to make use of it for my hosted node red application. Or if I have to write the scripting mechanisms to offload flow info from the nodered db and query all my other dbs for their respective _design docs and all the other configuration information required to set up an IoT node red application.
I forgot to mention, the copy/paste method loses information; you get no tab level metadata. The only way to get all the flow stuff is to pull if from the nodered flow record.
Node-RED will release a new version in a couple of days that will introduce projects, so you'll be able to use GitHub and all the usual tools to handle your app: https://twitter.com/NodeRED/status/956934949784956931 and https://nodered.org/docs/user-guide/projects/
While it doesn't address your short-term needs, I think it's the best long-term solution. Hopefully that helps.
I see these both in Bluemix, but what is the difference between them?
Cloud Foundry and OpenWhisk are two Bluemix Compute models that a developer can used to power an application's workload.
I'll give a very high-level summary of both services and when I would use them...
Cloud Foundry
IBM Bluemix was originally based off Cloud Foundry's open technology. It is a cloud computing platform as a service that supports the full lifecycle, from initial development, through all testing stages, to deployment.
Cloud Foundry has a CLI program called cf which is the primary tool to interact with Bluemix (or Bluemix provides a web GUI for this).
Cloud Foundry introduces the concepts of Organizations that contain Spaces which you can think of as workspaces. Different spaces typically correspond to different lifecycle stages for an application.
Cloud Foundry introduces the concepts of Services and Applications. A Cloud Foundry service usually performs a particular function (like a database service), and an application usually has services and their keys bound to it.
OpenWhisk
OpenWhisk is a brand new IBM Cloud developed distributed event-driven compute model.
It has a distributed automatically scaling serverless architecture that executes application logic on events.
OpenWhisk also has a CLI program called wsk which can be used to run your code snippets, or actions, on OpenWhisk.
OpenWhisk introduces the concepts of Triggers, Actions, and Rules.
Triggers are a class of events emitted by event sources.
Actions encapsulate the actual code to be executed which support multiple language bindings including Node.js, Swift and arbitrary binary programs encapsulated in Docker Containers. Actions invoke any part of an open ecosystem including existing Bluemix services for analytics, data, cognitive, or any other 3rd party service.
Rules are an association between a trigger and an action.
Cloud Foundry vs. OpenWhisk
So the question remains: when should you use Cloud Foundry, or when should you use OpenWhisk?
In my limited experience using OpenWhisk, here are my thoughts. I like to think of OpenWhisk as an easily implementable automatically scaling architecture that application developers can use without needing much prior knowledge in backend development. I think of Cloud Foundry as a lower level in the software stack which might give you more customization, but will likely take more skill and knowledge for setting it up.
I would use Cloud Foundry if I...
Was a backend & application developer.
Had experience creating and connecting services together.
Needed functionality that just might not be possible using OpenWhisk.
I would use OpenWhisk if I...
Was an application developer.
Didn't want to worry about a server.
Didn't want to learn different programming languages, etc. to figure out how to set up my server.
Really wanted focus on developing my application and have the backend just work.
Hope that helped.
Edit:
Here's a cool image that I found that illustrates this:
CloudFoundry is a PaaS (Platform-as-a-service) platform, which means in a nutshell, that it hosts the platform for your application to run on. Examples of a platform include node.js or a JVM.
OpenWhisk is a serverless platform. The term FaaS (Function-as-a-service) seems to be emerging as well. You upload code, which is executed once an event happens. That event might be anything, ranging from a simple HTTP request to a change happening in your database.
The fundamental difference between the two is the mode of operation. PaaS means, you're still running a server-process. You'll have a long running process which listens to events and executes your logic, once an event happens. All the other time, the process is idle, still requiring CPU cycles and memory to actually listen for events.
In serverless, the platform takes the burden of "listening for events". Once an event happens, your code is instantiated and executed. That code is shutdown afterwards thus not requiring any resources anymore. That also explains why OpenWhisk actions have a time limitation of 5 minutes. It is not meant to have long running actions.
Disclaimer: Both platforms support a lot more than I described here, I tried to keep it down to the most substantial difference between the both.
I have looked at the options in the portal and also the resource group templates, but could not find a way to customize this list.
Also, is it possible to add custom perf counters (assuming the code already creates them) for monitoring in the service fabric application?
There is no integrated way to do this today, but there are three ways to do this:
Use Application Insights to monitor your application. There are some
details of how to do this with Application Insights that are not Service
Fabric specific here. There is also a project on GitHub that shows
how to integrate Azure Service Fabric with Application Insights.
Collect performance counters using Azure Diagnostics. Service Fabric is running on VMs, configuring diagnostics to collection from
an Azure VM can be found here.
Use Operations Management Suite which can also collect standard and custom performance counters. See links in the post below (I'm not allowed to post more than 2 links)
You could also try this approach: Setting up Application Insights for your Service Fabric application
What is the difference between "App fabric workflow service" and "Workflow manager 1.0"
Both used to host workflows. For me workflow manager looks good because it is scalable, we can create workflow hosting farm using multiple servers.
will "Workflow manager" replace "appfabric workflow"? for new project what to select?
This is a tough one.
AppFabric Workflow Services (actually WCF workflow services) are hosted in WorkflowServiceHost, but to be honest, we can see that AppFabric workflow hosting is not really evolving much. Especially in combination with BizTalk tools (adapter & mapper) through BizTalk AppFabric connect, it is nice to build some things.
Workflow Manager is the technology that was shipped with SharePoint Server 2013, together with Service Bus for Windows Server. To be honest, it is a V1, but this will probably be the technology that will be evolved (especially since SharePoint is the biggest customer of this technology ;))
The nice thing about Workflow Manager is that it is built to be cloud-ready (isolation, scalability, security...). You also have the concept of the Trusted Surface (http://msdn.microsoft.com/en-us/library/windowsazure/jj193509(v=azure.10).aspx) This allows you to sandbox customization.
So, my bet would be: if your product/platform is a long term thing, go for Workflow Manager, but live with the V1 concepts, or ignore the Trusted Surface sandboxing.
If you build it for shorter term, go for AppFabric still.
Hope this helps
Jurgen Willis (http://blogs.msdn.com/b/workflowteam/archive/2012/10/24/announcing-the-release-of-workflow-manager-1-0.aspx) when announcing Workflow Manager 1.0 answered this question.
A major difference between them is that the AppFabric (for Workflows) is supposed to be for hosting Workflow Services based on WorkflowServiceHost(WFSH). Meaning that the workflows in AppFabric are all services and expect to be invoked as services consuming and exposing WCF Soap Services.
But the Workflow Manager can host any type of Workflow including services. You can have workflows initiated that does not receive or send any messages, but only does DB transactions.
Some follow up I found.
App Fabric is going to be discontinued according to this:
http://blogs.msdn.com/b/appfabric/archive/2015/04/02/windows-server-appfabric-1-1-ends-support-4-2-2016.aspx
And Sharepoint Server 2016 relies on App Fabric:
https://redmondmag.com/articles/2015/05/12/sharepoint-2016-and-infopath.aspx
Workflow Manager 1.0 was shipped with Sharepoint Server 2013 as mentioned previously in this thread. Does that mean that Workflow Manager is also discontinued or will it come as a version 2.0 when Sharepoint Server 2016 is released? Any other information about where all this is going is very welcome.
The question:
will "Workflow manager" replace "appfabric workflow"? for new project
what to select?
still seems unanswered to me.
Windows Workflow Foundation is such a great and potent framework, and it is troublesome if you don't have an on premise host system like AppFabric you can rely on.
Sam Vanhoutte is right:
Cons of workflow manager is that it really is a a V1 product, the two main issues that I ran into when using it were:
Workflows hosted in Workflow Manager are expected to be declarative: adding your own custom code can be tricky, documentation is not extensive.
Workflow manager does not allow you to force persistence of a workflow state easily. There is some mention that delay activities will persist state, however, the Persist Activity is explicitly not supported. I have run into cases while building workflows where the same activity is executed multiple times because of a problem in the hosting environment configuration or because an exception in a custom code activity crashes the host instead of suspending the workflow as it does when using AppFabric.
If you have the time to put in to learn the platform and deal with V1 issues I would definitely choose workflow manager, if you have experience with hosting in AppFabric be prepared for significant differences.
Windows fabric or service fabric are the ones which are used to form service bus cluster ring. Service fabric is used in sb1.1 with tls1.2 support version. The previous versions use windows fabric.
App fabric is not used by workflow manager. It is used by sharepoint.