Is it possible to get user telemetry (like number of unique users) by only configuring application insights to be in ASP.NET Core Startup.cs without adding the telemetry javascript to webpages?
Do requests telemetry enable us to know the number of unique users from both mobile app and webpage or the information about users is limited to applicationinsights javascript?
Actually, you can do this in a limited way without javascript.
You'd be limited to whatever information you collect from the inbound requests, which would include location information (derived from client ip address, which will only be used for geolocation, then thrown away), and whatever limited user/session information the server generates for you, and asp.net (including core) does do some of that already.
Application Insights uses the full incoming address (if there is one) to do geolocation, and then (as of ~Feb 2018) throws away the ip address.
Well, binary answer is No.
As client side telemetry need to be captured in client browser - JS option is the only choice. Requests & other telemetry can give you server side data but user specific data still need ai.js
Otherwise you can have audit on your own in addition to your authentication/authorization implementation.
Update:
John & James pointed out some useful info & links to achieve this from server side too.
Related
Imagine the following situation. I have an API and a developer builds an application that retrieves new content from it on a daily base. She stores this content and provides this data to all the instances of an app she developed. In this way these apps do not have to call the API directly.
Is there a way to prevent this and force the apps (and therefore the end users) to use the API and not only the application on the server.
I found many questions about how to cache API data but not how to prevent that. I am fairly new to this, so maybe I am overlooking something or maybe it is not possible to prevent this.
Thank you in advance!
Assuming you are using Apigee for API-management, you have some options. First, consider the options available to you contractually, if this is that sort of business relationship and you can impose certain API behavior with a business partner through a contract.
Separate from the legal side of things, we remember that you control your API and the credentials you issue for use by your API clients. You cannot though control, practically, what a client developer does with the credentials you issue: she could promise to embed the credentials in the mobile apps' API client, but change her mind and use it centrally, and then design her mobile client to call into her central cache. If though you really insist that only mobile app clients should be calling your API and not a hub/cache server, then you could consider applying constraint policies on your API (within the Apigee proxy, such as Access Control). For instance, you could blacklist your partner's hub/cache server IP address, although that is weak security at best. Or, you could apply a constraint that only clients with certain identifying User-Agent strings (mobile OS, client) are allowed to connect to your API. Or use GeoIP filtering to allow only clients from certain regions, if that applies to your use-case.
Finally, depending on the data model, you might be able to rate-limit such that a bulk cache becomes impractical: if your edge-client use-cases is to fetch a single record, but a cache would have to hold thousands of records, then you could impose a per-client rate limit (Quota policy) which is no bother to individual mobile clients, but makes the work of a hub/cache server untenable.
I realize a similar question has been asked here. Although it talks specifically of a custom domain, whereas i would want to send the data from the clients to the webserver where the serverside SDK is running and then send it from there. Is there any way to do this? We have PCs which will be stripped of direct internet access, however the webserver will not.
I think the answer from #John Gardner applies here - you need:
1. Send data from your app to your server/web server
2. In web server send data to Application Insights
I'm using application insights to get telemetry data off of my servers, but there is one server linked to my insights ID that i don't have access to, and it is giving me all sorts of bogus data. How do i filter out all of the telemetry from that server so that it doesn't appear alongside any of my other telemetry responses?
I know i can go into analytics and filter servers out there, but I'm talking about the main metrics page, the one that sends out alerts, shows a general overview of the servers, etc.
In short, there's no easy way to do it. you'd have to edit the filters on every part on every place in order to customize them, and pin those customized versions to dashboards and never look at the default experiences again.
How is there a server sending telemetry using your key you don't have access to? is it somewhere else where someone made a copy/paste error and somehow used your key?
i believe you can contact support and have them generate a new instrumentation key for that resource. then you'd update the places you do have under your control to use the new ikey, and the thing not under your control would still be using the old, now invalid key.
I'm designing a database monitoring application. Basically, the database will be hosted in the cloud and record-level access to it will be provided via custom written clients for Windows, iOS, Android etc. The basic scenario can be implemented via web services (ASP.NET WebAPI). For example, the client will make a GET request to the web service to fetch an entry. However, one of the requirements is that the client should automatically refresh UI, in case another user (using a different instance of the client) updates the same record AND the auto-refresh needs to happen under a second of record being updated - so that info is always up-to-date.
Polling could be an option but the active clients could number in hundreds of thousands, so I'm looking for a more robust and lightweight (on server) solution. I'm versed in .NET and C++/Windows and I could roll-out a complete solution in C++/Windows using IO Completion Ports but feel like that would be an overkill and require too much development time. Looked into ASP.NET WebAPI but not being able to send out notifications is its limitation. Are there any frameworks/technologies in Windows ecosystem that can address this scenario and scale easily as well? Any good options outside windows ecosystem e.g. node.js?
You did not specify a database that can be used so if you are able to use MSSQL Server, you may want to lookup SQL Dependency feature. IF configured and used correctly, you will be notified if there are any changes in the database.
Pair this with SignalR or any real-time front-end framework of your choice and you'll have real-time updates as you described.
One catch though is that SQL Dependency only tells you that something changed. Whatever it was, you are responsible to track which record it is. That adds an extra layer of difficulty but is much better than polling.
You may want to search through the sqldependency tag here at SO to go from here to where you want your app to be.
My first thought was to have webservice call that "stays alive" or the html5 protocol called WebSockets. You can maintain lots of connections but hundreds of thousands seems too large. Therefore the webservice needs to have a way to contact the clients with stateless connections. So build a webservice in the client that the webservices server can communicate with. This may be an issue due to firewall issues.
If firewalls are not an issue then you may not need a webservice in the client. You can instead implement a server socket on the client.
For mobile clients, if implementing a server socket is not a possibility then use push notifications. Perhaps look at https://stackoverflow.com/a/6676586/4350148 for a similar issue.
Finally you may want to consider a content delivery network.
One last point is that hopefully you don't need to contact all 100000 users within 1 second. I am assuming that with so many users you have quite a few servers.
Take a look at Maximum concurrent Socket.IO connections regarding the max number of open websocket connections;
Also consider whether your estimate of on the order of 100000 of simultaneous users is accurate.
I have a web application, where users will see notifications for their new messages, I want to push the notifications to the users who are already logged in.
I have seen that I can do it using Server Push of PokeIn, I have tried and understood the simple application using it, but I am not getting the ClientID thing.
The ClientId it saves in "OnClientConnected" is a simple integer, so how does it recognizes clients and calls functions on them ?
Also, it is written that it uses a hybrid long polling approach, can somebody please explain me what is this?
I will not be able to implement without having sufficient knowledge of it.
Does saving the ClientID in the database for logged in user and then pushing data using this will do ?
UPDATE:
Even from requests within the same
browser window or tab, the ClientId
received every time on every request
is different, so I had to include the
Handler in my master page and on every
request, I had to map the ClientId
received to the Logged In user, so
that I can send messages to him.
Can't I just map the (ClientId to
LoggedIn UserId) only once on LogIn
and then use that same ClientId to
send him messages ?
ClientID represents the identification key of the specific client view of your application and subject to change on each time.
It helps you to manage and target specific views by keys. On the other hand, you can still use ASP.NET session ids with PokeIn client ids.
The only difference is, if any user opens your application on the different tabs of same browser, each tab will have a unique client id. Actually, this is a great
functionality you may need. On the other hand, PokeIn also notifies you when a client is disconnected (almost instantly)..
You may reach session id by the client id;
CometWorker.GetSessionId(string ClientId)
or client ids for a session id by;
CometWorker.GetClientIdsBySessionId(string sessionId)
Additionally, if you don't want to use client id system (which is very useful), you may choose the "Joint" option. It helps you the send and receive messages from
the client with the name you have defined. (There is a sample for the "Joint" feature in here)
Because PokeIn provides various connection options, you don't have to think about the approach behind it when you work with PokeIn. It simply provides benefits
from the various solutions. More information can be accessible from : "FAQ" and "Advanced Tutorial" (http://www.pokein.com/Help/AdvancedTutorial.aspx)
At last, you don't have to save PokeIn client id to the database. PokeIn manages your server side objects per each client efficiently.
I suggest you to check the samples and tutorials.
As an answer for your update, you are free to use Joint feature of PokeIn when you need shared server side instances for the clients or consistent naming for the clients.