Most common metrics used along with Kanban are:
Cycle time / production lead time
There is some confusion over naming so let me explain in a bit more detail. Production lead time or cycle time is time that elapses from the moment a team starts actively working on a task till the moment they are done (or done-done). This metric basically say about how responsive the team is or how fast they can deliver something when priorities change.
Customer lead time
Time that elapses from the moment a customer or a user submits the work item to a backlog to the moment they can use it. In other words, if a feature is queued for long time in the backlog it would hit customer lead time while it won't hit cycle time / production lead time. This metric say about how the whole organization or product team (not only a development team) reacts to customer's needs.
Throughput
A measure of productivity or efficiency which is typically a number of features delivered over time. Some teams tend to weigh delivered features basing on assumption that a big feature is worth more than a small one but that's tricky at best.
Work in Progress (WIP)
Simply a number of work items that are currently in progress in the whole process. As a stand alone measure it doesn't make that much sense but it gives a lot of insight when combined with other measures. One classic example is Little's Law which adaptation to this context goes like this: Average Cycle Time = WIP / Average Throughput
Tact Time / Takt Time
A measure that says about frequency of delivering new work items. Tact time is Average Cycle Time divided by Average WIP. In other words it tells about throughput of a team and allows to assess whether remaining work would be done before a specific deadline.
There are tools that help to make sense out of these measures. A simplest one is a burn-up chart which is an alternative to burn-down chart that is more intuitive to use especially in cases where the scope changes frequently.
Another tool that shows even more is Cumulative Flow Diagram (CFD). CFD would show more data, e.g. give you sense of how much WIP is there in the system or what roughly are cycle times / production lead times and customer lead times.
Value
Now, the tricky part is that aforementioned measures and tools are tools to measure efficiency and not effectiveness, i.e. how well we are doing in accomplishing our long term goals. For the latter there is one crucial bit that is missing here--an idea what value is.
In other words the organization has to be able to answer the question how valuable each work item is or how it contributes to accomplishing long term goals. Only then you would be able to translate any efficiency measures to long term goal accomplishment.
Are we there yet?
Finally, there is a question you mention, which is an answer to a question what is project status. For that I would typically use a CFD and a forecast of progress basing on throughput over time (which is a curve representing done stage). However, instead of looking when it crosses current scope curve I'd use a forecast of scope change basing on how it was changing in the past. If it was growing over time the forecast would represent that. If new features substituted the old ones it should be pretty stable.
This would give you an answer about the estimated delivery date. While I don't think percent complete is, in such a setup, a very useful number I'd estimate it dividing a number of features done by estimated number of features at the end of the project, i.e. not the total number of features we have now.
This works under an assumption that the scope will be changing over time roughly in a similar manner as it did so far. This is something that the organization is in control of, e.g. you can decide that you don't add new stuff or remove some of the planned stuff. This would render the forecast of scope change irrelevant but this would also give additional data what kind of scope you work against.
